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FEL-98-A245 

Het  Target  Information  Command  and  Control  System  (TICCS)  dient  ingezet  te 
worden  ten  behoeve  van  de  KL-Iuchtverdediging.  Interoperabiliteit  vormt  hierbij 
het  sleutelwoord.  Gegevensuitwisseling  tussen  de  verschillende  organisatorische 
niveaus  moet  hierbij  snel  en  ongestoord  plaats  kunnen  vinden. 

Een  van  de  randvoorwaarden  van  TICCS  is  dat  het  systeem  moet  voldoen  aan  de 
ATCCIS-standaard  (Army  Tactical  Command  Control  and  Information  System). 

De  ATCCIS  studie  heeft  geresulteerd  in  standaarden  die  interoperabiliteit  op 
intemationaal  niveau  bewerkstelligen;  ISIS  (Geintegreerd  Staf  Informatiesysteem) 
is  de  Nederlandse  implementatie  van  een  Command  en  Control  Systeem  gebaseerd 
op  ATCCIS  specificaties.  Het  is  ontwikkeld  om  de  C2-processen  op  legerkorps-, 
divisie-  en  brigadeniveau  te  ondersteunen.  Aansluiten  op  ISIS  betekent  dat 
interoperabiliteit  met  andere  functionele  deelgebieden  zekergesteld  is. 

ISIS  heeft  momenteel  op  divisie-  en  brigadeniveau  geresulteerd  in  een 
infrastructuur  voor  gegevensuitwisseling  en  een  verzameling  van  herbruikbare 
componenten  (het  zogtnotmdt  framework).  Hierdoor  moeten  applicaties 
eenvoudiger,  sneller  en  efficienter  ontwikkeld  kunnen  worden.  In  dit  onderzoek 
wordt  nagegaan  wat  de  gevolgen  zijn  als  TICCS  op  ISIS  wordt  ontwikkeld  voor 
brigade-  en  divisieniveau;  welke  componenten  zijn  al  ontwikkeld,  welke  kunnen 
worden  (her)gebruikt  en  wat  dient  specifiek  voor  TICCS  te  worden  ontwikkeld. 
Daamaast  wordt  kort  ingegaan  op  de  koppeling  met  systemen  onder  brigadeniveau. 

Het  TICCS  is  -  als  informatiesysteem  -  te  beschouwen  als  een  samenspel  tussen 
verschillende  componenten:  "Gegevens  die  met  behulp  van  communicatiemiddelen 
uitgewisseld  worden  tussen  diverse  niveaus.  De  gegevens  worden  met  behulp  van 
applicaties  bewerkt.  De  samenhang  tussen  de  componenten  is  opgebouwd  rond 
een  bepaalde  architectuur.\ 


TNOrapport 


FEL-98-Aa45 


3 


Het  onderzoek  wordt  uitgevoerd  door  zowel  TICCS  als  ISIS  vanuit  verschillende 
perspectieven  te  belichten: 

Gegevens 

In  hoeverre  wordt  de  TICCS  gegevensbehoefte  afgedekt  door  ISIS. 
Communicatiemiddelen 

In  hoeverre  voldoen  de  communicatiemiddelen  die  voor  TICCS  ter 
beschikking  staan  (benodigde  bandbreedte,  performance  etc.). 

Software  /  Functionaliteit 

In  hoeverre  kan  voor  de  te  ontwikkelen  software  gebruik  gemaakt  worden 
van  onderdelen  van  het  ISIS-framework  en  welke  componenten  dienen 
specifiek  ontwikkeld  te  worden, 

Architectuur 

In  hoeverre  kan  gebruik  gemaakt  worden  van  de  door  ISIS  geleverde 
architectuur  (in  de  brede  zin  van  het  woord);  kan  de  configuratie  gebruikt 
worden  voor  de  gewenste  inzetopties  en  wordt  dan  voldaan  aan  de  eisen 
met  betrekking  tot  flexibiliteit,  robuustheid  en  performance. 

In  het  kort  worden  hieronder  de  bevindingen  van  dit  onderzoek  uiteengezet. 

Gegevens 

ISIS  maakt  gebruik  van  twee  datamodellen:  Het  applicatiemodel  en  het 
uitwisselmodel.  De  applicaties  hebben  alleen  met  het  applicatiemodel  te  maken; 
dit  model  is  eenvoudiger  van  opzet  en  bevat  slechts  een  subset  van  de  totale  C2- 
gegevens.  De  gegevens  van  het  applicatiemodel  worden  automatisch  vertaald  naar 
het  uitwisselmodel,  waama  ze  gecommuniceerd  kunnen  worden  met  andere  ISIS- 
knooppunten. 

Veel  van  de  door  TICCS  benodigde  gegevens  zijn  al  aanwezig  in  het  ISIS- 
uitwisselmodel.  Er  zijn  slechts  beperkte  aanpassingen  aan  het  uitwisselmodel 
nodig  om  de  totale  TICCS-gegevensbehoefte  af  te  kunnen  dekken  (dit  hoeft  niet  te 
betekenen  dat  er  ook  functionaliteit  beschikbaar  is  om  de  gegevens  te  kunnen 
bewerken).  In  tegenstelling  hiermee  zal  het  ISlS-applicatiemodel  wel  uitgebreid 
dienen  te  worden  (lees:  een  groter  gedeelte  van  het  ISIS-uitwisselmodel  moeten 
bevatten)  om  de  door  TICCS  benodigde  gegevens  voor  de  applicaties  beschikbaar 
te  stellen. 

Communicatie 

De  processen  op  brigade-  en  divisieniveau  zijn  -  voor  zover  het  de  lua  betreft  -  in 
het  algemeen  niet  extreem  tijdkritisch.  Veelal  is  vooraf  bekend  wanneer  welke 
gegevens  op  de  plaats  van  bestemming  aanwezig  dienen  te  zijn  en  kan  hierop 
geanticipeerd  worden.  ISIS  voldoet  in  dergelijke  gevallen  aan  de  gewenste 
behoefte.  In  het  geval  van  minute-to-minute-control  ligt  dat  anders.  Dergelijke 
gegevens  dienen  zo  snel  mogelijk  en  met  de  hoogste  prioriteit  tot  op  het  laagste 
niveau  te  worden  doorgegeven;  gesteld  is  dat  dit  ten  hoogste  een  minuut  mag 
duren.  Het  gaat  hierbij  bijvoorbeeld  om  de  creatie  van  een  'safe  lane'  waardoor 
helikopters  veilig  over  de  eigen  linies  geloodst  kunnen  worden.  Omdat  men  op 
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brigade-  en  divisieniveau  de  beschikking  heeft  over  een  ZODIAC  network  is  er 
voldoende  bandbreedte  beschikbaar.  Onder  normale  omstandigheden  wordt  op 
divisie-  en  brigadeniveau  aan  de  gestelde  eis  van  een  minuut  voldaan  (zonder  de 
gegevens  te  fiiteren).  Probleem  is  dat  ISIS  hiervoor  geen  harde  garantie  kan  geven. 
Om  hierover  meer  zekerheid  te  verkrijgen  dient  het  mogelijk  te  zijn  om  prioriteiten 
aan  gegevens  toe  te  kennen,  zodat  dringende  gegevens  via  een  ander 
communicatiekanaal  of  met  voorrang  behandeld  kunnen  worden.  Indien  een 
dergelijke  garantie  geeist  wordt  zijn  aanpassingen  aan  ISIS  noodzakelijk.  De 
omvang  van  de  aanpassingen  zijn  afhankelijk  van  de  ontwikkelingen  binnen  de 
C2-onderlaag  (alles  onder  brigadeniveau,  voor  meer  details  wordt  verwezen  naar 
het  gedeelte  ‘Architectuur’). 

Hoewel  de  beschikbare  bandbreedte  op  de  brigade  en  de  batterij  sterk  verschillend 
is,  dient  de  voor  de  lua-officier  beschikbare  functionaliteit  op  deze  niveaus  gelijk 
te  zijn. 

Software  /  Functionaliteit 

Veel  van  de  gewenste  Airspace  Control  functionaliteit  bestaat  uit  (geo)grafische 
manipulaties  op  een  stafkaart.  Een  voorbeeld  hiervan  is  het  samenstellen  van  een 
ACO  (Airspace  Control  Order,  de  orders  voor  het  beheer  van  het  luchtruim  voor 
de  komende  periode).  Voorgesteld  wordt  speciale  ’Current-ACO'  -  en  'Next-ACO - 
oleaten  te  ontwikkelen  die  de  gegevens  vanuit  verschillende  bronnen  (legerkorps, 
divisie  en  brigade)  inzichtelijk  maken  en  actueel  houden.  Hierbij  zal  het  gebruik 
van  het  ISIS-framework  zeer  veel  ontwikkelwerk  besparen. 

Voor  minute-to-minute-control  zal  de  user-interface  op  een  aantal  punten 
aangepast  moeten  worden  zodat  de  gebruiker  snel  en  eenvoudig  Airspace  Control 
Means  (de  middelen  die  nodig  zijn  om  het  luchtruim  te  beheren)  kan  vastleggen. 
Indien  het  stellen  van  prioriteiten  noodzakelijk  blijkt  zullen  veranderingen  in  de 
ISIS-architectuur  noodzakelijk  zijn, 

Functionaliteit  voor  het  omgaan  met  orders  en  bevelen  is  grotendeels  al  aanwezig 
in  ISIS.  Hiervoor  kan  van  het  Tactical  Message  System  (TMS)  gebruik  gemaakt 
worden.  De  Subject  Indicator  Codes  (SICs)  bepalen  dan  naar  welke  gebruikers 
binnen  een  eenheid  de  gegevens  worden  gedistribueerd. 

Doelinformatie  dat  afkomstig  is  van  de  radarsensoren  kan  ook  op  ISIS-stations 
worden  afgebeeld.  Korte  testen  hebben  aangetoond  dat  het  afbeelden  van  30 
doelen  binnen  2  seconden  mogelijk  is.  Met  relatief  weinig  inspanning  kan  ook 
deze  functionaliteit  gerealiseerd  worden. 

Architectuur 

Naarmate  er  meer  functionele  deelgebieden  aansluiten  op  ISIS  neemt  de  behoefte 
aan  filtering  toe.  Deze  functionaliteit  is  weliswaar  aanwezig  in  ISIS,  maar  nog  niet 
gebruikt.  Dit  hangt  direct  samen  met  het  feit  dat  er  momenteel  voldoende 
bandbreedte  beschikbaar  is  (voor  divisie  en  brigade).  Binnen  ISIS  worden 
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momenteel  alle  gegevens  direct  -  en  ongefilterd  -  gerepliceerd  naar  andere 
knooppunten.  Indien  filtering  toegepast  zou  worden  kost  dit  enige  tijd:  bij  gebruik 
van  complexe  filters  wordt  emaar  gestreefd  de  gegevens  binnen  10  minuten  op  de 
knooppunten  aanwezig  te  laten  zijn. 

Binnen  TICCS  zijn  filters  nodig,  maar  is  het  tegelijkertijd  nodig  dat  de  gegevens 
direct  verstuurd  worden  (in  het  geval  van  minute-to-minute-control).  Er  dient  een 
aantal  performance-verbeterende  activiteiten  (en  eventueel  wijzigingen  in  de 
architectuur)  doorgevoerd  te  worden  om  dit  mogelijk  te  maken,  Indien  ISIS  wordt 
toegepast  voor  de  C2-onderlaag  is  filtering  beslist  noodzakelijk. 

De  communicatie  met  de  batterij  verloopt  vooralsnog  via  een  FM9000  verbinding. 
De  batterijcommandant,  die  zich  afwisselend  op  de  brigade-  en  batterij- 
commandopost  begeeft,  dient  op  beide  posten  dezelfde  functionaliteit  tot  zijn 
beschikking  te  hebben.  De  buitenkant  van  het  C2-systeem  op  de  batterij  en  de 
brigade  dient  in  elk  geval  dezelfde  look-and-feel  te  hebben,  Onduidelijk  is 
momenteel  nog  hoe  de  C2-informatievoorziening  binnen  de  C2-onderlaag  zal 
worden  gerealiseerd.  Duidelijk  is  wel  dat  er  een  Vertaling’  zal  moeten  plaatsvinden 
om  de  C2-functionaliteit  van  de  C2-onderlaag  (alles  onder  brigadeniveau) 
naadloos  te  laten  aansluiten  op  die  van  de  C2-bovenlaag  (brigadeniveau  en  hoger). 
Pas  als  deze  functionaliteit  gerealiseerd  is  zijn  uitspraken  te  doen  over  de 
performance  van  het  totale  C2-gedeelte  van  TICCS. 

Bij  minute-to-minute-control  dienen  de  gegevens  met  een  hoge  verzendprioriteit  te 
worden  verstuurd.  Voor  divisie-  en  brigadeniveau  is  de  kans  groot  dat  de  gegevens 
binnen  de  gestelde  tijd  aankomen.  Nadeel  is  dat  ISIS  hiervoor  geen  garantie  kan 
geven.  Dit  is  mede  en  gevolg  van  het  feit  dat  er  geen  prioriteiten  aan  berichten 
gegeven  kunnen  worden.  Indien  een  dergelijke  garantie  wel  geeist  wordt  dienen 
performance  verbeteringen  aangebracht  te  worden  en  -  afhankelijk  van  het 
resultaat  hiervan  -  ook  wijzigingen  in  de  architectuur  te  worden  doorgevoerd. 

Robuustheid  en  betrouwbaarheid  zijn  belangrijke  eisen  die  aan  TICCS  gesteld 
worden;  de  lua  moet  immers  onder  alle  omstandigheden  haar  taken  kunnen 
uitvoeren,  ook  als  gedeelten  van  het  systeem  zijn  uitgevallen.  ISIS  zal  daarom 
verder  'gestabiliseerd'  moeten  worden  om  aan  deze  eis  tegemoet  te  komen.  Indien 
het  systeem  desondanks  niet  beschikbaar  is  wordt  voorgesteld  functionaliteit  in  te 
bouwen  die  aansluiting  geeft  op  de  manier  waarop  momenteel  gewerkt  wordt  (o.a. 
ACO's  in  tekstueel  formaat  kunnen  genereren  en  inlezen).  Deze  functionaliteit 
vertoont  grote  gelijkenis  met  functionaliteit  die  binnen  ISIS  als  add-in  al  voor 
HERDS  ontwikkeld  is. 

Naar  aanleiding  van  het  onderzoek  is  een  aantal  technische  en  organisatorische 
risico’  geformuleerd  en  zijn  aanbevelingen  gedaan  om  de  risico’s  in  een  aantal 
stappen  te  minimaliseren.  In  het  laatste  hoofdstuk  zijn  zowel  de  risico’s  als  de 
aanbevelingen  verwoord. 
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Samenvatting 

Het  Target  Information  Command  and  Control  System  (TICCS)  dient  ingezet  te 
worden  ten  behoeve  van  de  KL-Iuchtverdediging.  Gegevensuitwisseling  tussen  de 
verschillende  organisatorische  niveaus  dient  hierbij  snel  en  ongestoord  plaats  te 
kunnen  vinden. 

Als  belangrijke  randvoorwaarde  voor  TICCS  is  opgelegd  dat  het  systeem  moet 
voldoen  aan  de  ATCCIS-standaarden.  ISIS  (Geintegreerd  Staf  Informatiesysteem) 
is  de  Nederlandse  imiementatie  van  een  Command  en  Control  Systeem  gebaseerd 
op  ATCCIS  specificaties.  In  het  kader  van  ISIS  is  de  C2-infrastructuur  op  divisie- 
en  brigadeniveau  al  ontwikkeld.  Daamaast  heeft  ISIS  een  verzameling 
herbruikbare  componenten  (het  zogenoemde  ’framework’)  opgeleverd  dat 
applicatieontwikkeling  moet  vereenvoudigen  en  versnellen. 

In  dit  haalbaarheidsonderzoek  wordt  vastgesteld  wat  de  consequenties  -  en 
eventuele  risico’s  -  zijn  als  ISIS  wordt  gebruikt  als  basis  voor  TICCS  op  divisie-  en 
brigadeniveau.  Het  onderzoek  is  uitgevoerd  door  het  TICCS  vanuit  de  volgende 
perspectieven  te  belichten: 

•  Wordt  de  TlCCS-geg^v^njbehoefte  afgedekt  door  ISIS? 

•  Voldoen  de  voor  de  divisie  en  brigade  aanwezig  communicatiemiddelenl 

•  Kan  de  TlCCS-functionaliteit  met  behulp  van  ISIS  worden  ontwikkeld? 

•  Voldoet  de  ISlS-architectuur  voor  TICCS? 

Gegevens 

ISIS  maakt  gebruik  van  twee  datamodellen:  Het  applicatiemodel  en  het 
uitwisselingsmodel.  De  applicaties  hebben  alleen  met  het  applicatiemodel  te 
maken;  dit  model  is  eenvoudiger  van  opzet  en  bevat  slechts  een  subset  van  de 
totale  C2-gegevens.  De  gegevens  van  het  applicatiemodel  worden  automatisch 
vertaald  naar  het  uitwisselingsmodel,  waama  ze  gecommuniceerd  kunnen  worden 
met  andere  ISIS-knooppunten. 

Er  zijn  slechts  beperkte  aanpassingen  aan  het  ISIS-uitwisselmodel  nodig  om  de 
complete  TlCCS-gegevensbehoefte  af  te  kunnen  dekken.  Het  ISIS-applicatiemodel 
zal  wel  uitgebreid  dienen  te  worden  om  de  gegevens  van  het  ISIS-uitwisselmodel 
aan  de  applicaties  beschikbaar  te  stellen. 

Communicatie 

Binnen  de  C2-bovenlaag  (divisie-  en  brigadeniveau)  wordt  -  onder  normale 
omstandigheden  -  voldaan  aan  de  gestelde  eisen.  Hiervoor  kan  ISIS  echter  geen 
garantie  geven.  Indien  dit  wel  noodzakelijk  is  zullen  architecturele  voorzieningen 
getroffen  moeten  worden  (zie  ook  ’Architectuur').  Op  het  gebied  van  communicatie 
kan  de  C2-onderlaag  (alle  niveaus  onder  brigade)  niet  los  gezien  worden  van  de 
C2-bovenlaag. 
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Functionaliteit 

Door  gebruik  te  maken  van  het  ISIS-framework  bij  het  realiseren  van  de  gewenste 
functionaliteit  voor  de  C2-bovenlaag  zal  zeer  veel  ontwikkelwerk  bespaard 
worden.  Op  een  beperkt  aantal  punten  zal  het  bestaande  ISIS-GIS  aangepast 
moeten  worden  om  aan  de  gestelde  eisen  te  kunnen  voldoen.  Ook  het  afbeelden 
van  doelinformatie  is  met  behulp  van  het  framework  -  met  relatief  weinig 
inspanning  -  mogelijk. 

Architectuur 

Indien  minute-to-minute-control  buiten  beschouwing  wordt  gelaten  voldoet  de 
huidige  ISIS-architectuur  -  mits  voldoende  stabiel  -  voor  de  TICCS  C2-bovenlaag. 
Zelfs  het  afbeelden  van  het  luchtbeeld  is  -  met  behulp  van  het  ISIS-framework  - 
relatief  eenvoudig  te  realiseren.  Wordt  minute-to-minute-control  en  de  verbinding 
met  de  C2-onderlaag  wel  in  beschouwing  genomen  dan  kunnen  geen  garanties 
gegeven  worden  dat  aan  de  performance-eisen  voldaan  wordt.  Er  zal  een  aantal 
performance  verbeterende  factoren  doorgevoerd  moeten  worden  en  afhankelijk 
van  het  resultaat  hiervan  zal  de  architectuur  op  een  aantal  punten  aangepast 
moeten  worden  om  aan  de  gestelde  eisen  te  voldoen.  Het  is  hierbij  nodig  dat  ook 
van  filtering  gebruik  kan  worden  gemaakt  en  dat  prioriteiten  gesteld  kunnen 
worden.  Afhankelijk  van  de  invulling  van  de  C2-onderlaag  moet  bezien  worden  tot 
hoever  de  performance  van  de  C2-bovenlaag  verhoogd  moet  worden. 
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1.  Inleiding 

Het  Target  Information  Command  and  Control  System  (TICCS)  voor  de 
luchtdoelartillerie  van  de  Koninklijke  Landmacht  heeft  als  doel  het  verhogen  van 
de  luchtverdedigingscapaciteit  van  de  beschikbare  luchtverdedigingsmiddelen  en 
het  optimaliseren  van  het  luchtverdedigingsconcept. 

Een  van  de  eisen  die  aan  TICCS  wordt  gesteld  is  dat  het  systeem  moet  voldoen  aan 
de  ATCCIS  (Army  Tactical  Command  and  Control  System)  standaarden. 

ISIS  (Geintegreerd  Staf  Informatie  Systeem)  is  de  Nederlandse  implementatie 
gebaseerd  op  de  ATCCIS  specificaties.  Het  voorziet  in  de  informatie-infrastructuur 
voor  de  staf  op  divisie-  en  brigadeniveau.  Daamaast  is  ISIS  zodanig  opgezet  dat 
losse  componenten  voor  andere  toepassingen  hergebruikt  kunnen  worden.  Door 
systemen  op  basis  van  ISIS  te  ontwikkelen  kan  veel  ontwikkelwerk  bespaard 
worden  en  kan  optimaal  geprofiteerd  worden  van  de  bestaande  infrastructuur. 

In  dit  rapport  wordt  nagegaan  wat  de  gevolgen  zijn  als  TICCS  op  ISIS  wordt 
ontwikkeld  voor  brigade-  en  divisieniveau;  welke  componenten  zijn  al  ontwikkeld, 
welke  kunnen  worden  (her)gebruikt  en  wat  dient  specifiek  voor  TICCS  te  worden 
ontwikkeld.  Daamaast  wordt  kort  ingegaan  op  de  koppeling  met  C2-systemen 
onder  brigadeniveau. 

Hoofdstuk  2  bakent  de  doelstelling  af  en  geeft  aan  hoe  het  onderzoek  uitgevoerd 
zal  worden.  Hoofdstuk  3  gaat  in  op  ISIS;  hoe  is  ISIS  ontstaan,  uit  welke 
componenten  is  ISIS  opgebouwd  en  welke  functionaliteit  wordt  geboden. 
Hoofdstuk  4  belicht  TICCS  vanuit  verschillende  perspectieven  teneinde  een  beeld 
te  schetsen  van  de  TICCS  situatie  op  brigade-  en  divisieniveau.  Beide 
hoofdstukken  (ISIS  en  TICCS)  zijn  nodig  om  te  komen  tot  de  kem  van  het 
onderzoek:  De  haalbaarheid  van  TICCS  met  behulp  van  ISIS.  Bij  het  onderzoeken 
van  de  haalbaarheid  worden  zowel  ISIS  als  TICCS  vanuit  de  volgende 
invalshoeken  belicht: 

•  Gegevens  (Hoofdstuk  5). 

•  Communicatie  (Hoofdstuk  6). 

•  Functionaliteit  (Hoofdstuk  7). 

•  Architectuur  (Hoofdstuk  8). 

In  elk  van  de  voorheen  genoemde  vier  hoofdstukken  bevat  de  laatste  paragraaf  een 
samenvatting. 

Hoofdstuk  9  tenslotte  bevat  conclusies,  risico’s  en  aanbevelingen. 


TNO-rapport 


FEL-98-A245 


TNO-rappOft 


FEL-98-A245 


13 


2.  Doelstelling 


Een  van  de  randvoorwaarden  die  aan  het  Target  Information  Command  and 
Control  System  wordt  gesteld  is  dat  het  systeem  dient  te  voldoen  aan  de  ATCCIS 
specificaties.  ATCCIS  biedt  level  5  interoperabiliteit  (automatische  selectieve 
gegevensuitwisseling  op  database-niveau)  tussen  toekomstige  C2  systemen. 
Hierdoor  is  het  mogelijk  op  intemationaal  niveau  Command  en  Control  gegevens 
uit  te  wisselen. 

De  doelstelling  van  dit  onderzoek  is  om  -  voor  divisie-  en  brigadeniveau  -  na  te 
gaan  wat  de  consequenties  en  risico’s  zijn  als  TICCS  op  ISIS  gebouwd  wordt; 
welke  componenten  uit  ISIS  kunnen  worden  hergebruikt,  welke  onderdelen  moeten 
geheel  nieuw  ontwikkeld  worden  en  welke  onderdelen  uit  ISIS  dienen 
gemodificeerd  te  worden.  Indien  knelpunten  optreden  wordt  aangegeven  welke 
activiteiten  ondemomen  dienen  te  worden  om  deze  op  te  lossen. 

Het  TICCS  is  -  als  informatiesysteem  -  te  beschouwen  als  een  samenspel  tussen 
verschillende  componenten:  'Gegevens  die  met  behulp  van  communicatiemiddelen 
uitgewisseld  worden  tussen  diverse  niveaus.  De  gegevens  worden  met  behulp  van 
applicaties  bewerkt.  De  samenhang  tussen  de  componenten  is  opgebouwd  rond 
een  bepaalde  architectuur,\ 

Het  onderzoek  wordt  uitgevoerd  door  zowel  TICCS  als  ISIS  vanuit  verschillende 
perspectieven  te  belichten: 

Gegevens 

In  hoeverre  wordt  de  TICCS  gegevensbehoefte  afgedekt  door  ISIS. 
Communicatiemiddelen 

In  hoeverre  voldoen  de  communicatiemiddelen  die  voor  TICCS  ter 
beschikking  staan  (benodigde  bandbreedte,  performance  etc.). 

Software  /  Functionaliteit 

In  hoeverre  kan  voor  de  te  ontwikkelen  software  gebruik  gemaakt  worden 
van  onderdelen  van  het  ISIS-framework  en  welke  componenten  dienen 
specifiek  ontwikkeld  te  worden. 

Architectuur 

In  hoeverre  kan  gebruik  gemaakt  worden  van  de  door  ISIS  geleverde 
architectuur  (in  de  brede  zin  van  het  woord);  kan  de  configuratie  gebruikt 
worden  voor  de  gewenste  inzetopties  en  wordt  dan  voldaan  aan  de  eisen 
met  betrekking  tot  flexibiliteit,  robuustheid  en  performance. 
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Bij  de  totstandkoming  van  dit  rapport  zijn  de  volgende  uitgangspunten  gehanteerd: 

•  Er  wordt  uitgegaan  van  de  huidige  organisatie-structuur  van  de 
luchtdoelartillerie. 

•  Het  onderzoek  richt  zich  op  divisie-  en  brigadeniveau;  er  wordt  beperkt 
ingegaan  op  de  koppeling  met  batterijniveau; 

•  Er  wordt  alleen  ingegaan  op  de  TICCS  gerelateerde  aspecten  voor  wat  betreft 
communicatie,  te  bieden  functionaliteit  etc. 

•  Voor  zover  relevant  wordt  ervan  uitgegaan  dat  voor  communicatie  op  lagere 
niveaus  gebruik  wordt  gemaakt  van  de  FM9000. 

•  Er  wordt  -  tenzij  uitdrukkelijk  anders  vermeld  -  uitgegaan  van  de  ISIS- 
configuratie  zoals  die  in  februari  1998  is  opgeleverd. 
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3.  ISIS 

3.1  Inleiding 

ISIS  staat  voor  Geintegreerd  Staf  Informatiesysteem.  Het  voorziet  in  de  informatie- 
infrastructuur  voor  Command  &  Control  Systemen  binnen  de  KL.  De  doel- 
stellingen  van  ISIS  zijn  vastgelegd  in  paragraaf  2. 

ISIS  is  gebaseerd  op  intemationale  ATCCIS  (Army  Tactical  Command  and 
Control  Information  System)  specificaties;  in  paragraaf  3  wordt  hier  kort  op 
ingegaan.  Paragraaf  4  geeft  een  beschrijving  van  de  ISIS-architectuur,  waama 
paragraaf  5  ingaat  op  de  functionele  componenten. 


3.2  Doelstelling 

Het  doel  van  ISIS  is  het  bieden  van  66n  informatie-infrastructuur  die  geschikt  is 
om  de  staf  (op  legerkorps-,  divisie-  en  brigadeniveau)  te  ondersteunen  in  de  uit  te 
voeren  taken  en  opdrachten,  zowel  in  een  kantooromgeving  als  in  een  operationele 
omgeving  (crisisbeheersing,  humanitaire  hulpverlening,  grootschalig  optreden). 

Doordat  de  kantooromgeving  en  de  operationele  omgeving  binnen  ISIS  erg  nauw 
op  elkaar  aansluiten  kan  de  (staf)medewerker  in  een  tactische  omgeving  over 
dezelfde  functionaliteit  beschikken  als  in  de  kantooromgeving.  Langs  welke  weg 
de  communicatie  plaatsvindt  is  voor  de  gebruiker  in  principe  transparant. 


3.3  ATCCIS 

ATCCIS  staat  voor  ‘Army  Tactical  Command  and  Control  Information  System’. 
Het  is  een  intemationale  studie  geinitieerd  door  SHAPE  en  uitgevoerd  door 
NAVOpartners  naar  de  verbetering  van  interoperabiliteit  tussen  Command  & 
Control  systemen. 

De  doelstelling  is  om  intemationaal  geaccepteerde  standaarden  te  ontwikkelen 
voor  informatie-uitwisseling.  Uiteindelijk  heeft  dit  geresulteerd  in  specificaties 
voor  een  datamodel  en  in  protocollen  hoe  informatie  uitgewisseld  moet  worden. 
Het  ATCCIS  Replicatie  Mechanisme  (ARM)  is  een  implementatie  gebaseerd  op 
het  datamodel  en  de  protocollen. 
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Indien  informatiesystemen  aan  deze  specificaties  voldoen  is  sprake  van  NIPD  level 
5  interoperabiliteit  (interoperabiliteit  op  database  niveau).  Informatiesystemen 
kunnen  dan  -  onafhankelijk  van  bet  te  gebruiken  databasemanagementsysteem,  de 
gebruikte  hardware,  software  of  het  gebruikte  besturingssysteem  -  gegevens 
uitwisselen.  Bij  een  multinationaal  optreden  kunnen  partners,  ondanks  het  gebruik 
van  eigen  systemen,  op  deze  manier  toch  over  een  eenduidig  beeld  van  de  actuele 
situatie  beschikken. 

ISIS  is  de  Nederlandse  implementatie  gebaseerd  op  de  ATCCIS  specificaties. 


3.4  Architectuur 

ISIS  biedt  den  informatie-infrastructuur  voor  zowel  de  kantooromgeving  als  de 
operationele  omgeving.  Toch  zijn  er  belangrijke  verschillen  tussen  het  werken  in 
een  kantooromgeving  en  een  operationele  omgeving. 

•  In  een  operationele  omgeving  is  de  staf  opgedeeld  in  een  aantal  onderdelen  die 
elk  (fysiek)  zelfstandig  moeten  kunnen  optreden. 

•  In  een  operationele  omgeving  wordt  voor  communicatiefaciliteiten 
teruggevallen  op  apparatuur  met  een  relatief  lage  bandbreedte. 

•  In  een  operationele  omgeving  is  de  werk-  en  tijdsdruk  vaak  hoger. 

•  Een  zelfstandige  eenheid  dient  mobiel  te  zijn;  na  de  verplaatsing  (en  soms 
zelfs  tijdens  de  verplaatsing)  dient  de  infrastructuur  en  de 
applicatiefunctionaliteit  weer  beschikbaar  te  zijn. 

Om  dit  te  bereiken  is  de  kleinste  samengestelde  eenheid  van  personen  en  de  door 
hen  gebruikte  informatiesystemen  benoemd  die  zelfstandig  moet  kunnen  optreden. 
Binnen  ISIS  wordt  dit  de  Operationele  Module  genoemd.  Omdat  dit  begrip  van 
belang  is  binnen  de  ISIS-context  en  hier  later  naar  gerefereerd  wordt,  zal  eerst  de 
definitie  van  een  Operationele  Module  gegeven  worden  zoals  die  binnen  ISIS 
wordt  gehanteerd: 

Een  Operationele  Module  is  een  venameling  personen  en  middelen  die 
ten  behoeve  van  het  uitoefenen  van  eenfunctie  in  een  operationele 
omgeving  (crisisbeheersing,  humanitaire  hulpverlening,  grootschalig 
optreden)  technisch  onafhankelijk  kan  worden  ingezet. 

Voorbeelden  van  Operationele  Modulen  zijn  actieve  commandopost  (acp),  reserve 
commandopost  (rep)  en  de  hoofd  commandopost  (main  cp)  of  een  sensor. 

Binnen  de  ISIS-architectuur  speelt  de  database  een  centrale  rol.  Hike  operationele 
module  beschikt  over  66n  of  meer  databases.  De  gegevens  in  de  database  die 
afkomstig  zijn  van  andere  operationele  modulen  worden  geactualiseerd  door  het 
replicatiemechanisme.  Met  behulp  van  contracten  wordt  vastgelegd  op  welke 
gegevens  het  knooppunt  (de  technische  aanduiding  voor  een  operationele  module) 
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zich  abonneeit.  Indian  zich  wijzigingen  in  de  geabonneerde  gegevens  voordoen 
wordt  het  knooppunt  door  de  onderliggende  datacommunicatiefaciliteiten  op  de 
hoogte  gehouden  van  deze  wijzigingen.  Het  fysieke  medium  waarvan  gebruik 
gemaakt  wordt  is  hierbij  transparant  (zie  ook  onderstaande  figuur). 

Naast  de  huidige  beschikbare  C2  applicaties  (GIS,  ORBAT-browser)  wordt  voor 
algemene  toepassingen  gebruik  gemaakt  van  COTS  (Commercial  of  the  Shelf) 
produkten.  Indian  gegevens  (ongestructureerde  gegevens  die  geen  onderdeel 
uitmaken  van  de  database)  uitgewisseld  moeten  worden  met  andere  knooppunten 
kan  rechtstreeks  gebruik  gemaakt  worden  van  de  datacommunicatie  faciliteiten  (E- 
mail  danwel  het  later  te  bespreken  Tactical  Message  System).  Het  hardware 
platform  bestaat  uit  (portable)  PC’s.  In  onderstaand  figuur  is  dit  schematisch 
weergegeven. 


Figuur  1:  Basisarchitectuur  van  ISIS. 

De  basisarchitectuur  is  geimplementeerd  volgens  het  client-server  concept.  Een  of 
meer  clients  zijn  verbonden  met  de  server.  De  applicaties  werken  op  de  clients, 
terwijl  de  server  dienst  doet  als  database-  en  replicatieserver  (eventueel  verspreid 
over  een  aantal  fysieke  systemen). 
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De  ISIS-applicaties  maken  gebruik  van  het  Applicatie  Framework.  Dit  Framework 
heeft  twee  doelstellingen: 

1 .  Het  bieden  van  een  set  herbruikbare  componenten.  Dit  moet  de  ontwikkeling 
van  nieuwe  applicaties  gebaseerd  op  ISIS  versnellen  en  de  mogelijkheid  bieden 
om  de  functionaliteit  van  bestaande  applicaties  uit  te  breiden  (onder  andere 
door  gebruik  te  maken  van  de  zogenoemde  ‘add-in’  techniek). 

2.  Het  integreren  van  functionele  componenten  die  zowel  binnen  als  buiten  ISIS 
zijn  ontwikkeld.  Dit  wordt  bereikt  door  vooraf  richtlijnen  voor  interfaces  en 
templates  vast  te  leggen. 


Figuur  2:  Gelaagde  ophouw  van  het  framework 

Als  nieuwe  functionaliteit  wordt  gerealiseerd  met  behulp  van  het  Framework  heeft 
dit  de  volgende  voordelen: 

•  applicaties  kunnen  sneller  ontwikkeld  worden  door  gebruik  te  maken  van  reeds 
eerder  ontwikkelde  (delen  van)  applicaties; 

•  de  ontwikkeling  van  applicaties  zal  goedkoper  zijn; 

•  uniformiteit:  de  applicaties  sluiten  voor  wat  betreft  ‘look-and-feel’  aan  bij  de  al 
ontwikkelde  ISIS-applicaties; 

In  voorgaand  figuur  is  dit  weergegeven.  Nieuw  te  ontwikkelen  applicaties  kunnen 
voortbouwen  op  onderliggende  lagen. 


In  de  volgende  paragrafen  wordt  dieper  ingegaan  op  de  volgende  functionele 
componenten: 

Onderdelen  van  het  ISIS- fundament: 

•  Communicatie  infrastructuur. 

•  Database. 

•  Replicatie. 

Applicaties: 

•  GIS  appbcatie  en  de  HEROS  gateway. 

•  ORBAT-browser. 

•  Office  applicaties. 

•  Exchange  en  formeel  berichtenverkeer. 


3.5  Functionele  componenten 

3.5.1  Communicatie-infrastructuur 

ISIS  biedt  een  communicatie-infrastructuur  in  zowel  een  kantooromgeving  als  in 
een  operationele  omgeving.  In  de  kantooromgeving  wordt  er  tussen  de  kazemes 
gebruik  gemaakt  van  KLIM  (KL  Implementatie  Middenlaag). 

In  een  tactische  omgeving  wordt  voor  de  communicatie  tussen  staven  gebruik 
gemaakt  van  een  tactisch  network.  Dit  netwerk  bestaat  uit  transportabele  WAN- 
boxen  met  netwerkcomponenten  en  bekabeling.  Voor  interlokale  koppelingen  kan 
gebruik  gemaakt  worden  van  diverse  communicatiemiddelen:  ZODIAC,  SATCOM, 
MDTN  en  PTT.  Voor  de  verbinding  tussen  brigade  en  lagere  eenheden  wordt 
gebruik  gemaakt  van  de  FM-9000  Combat  Net  Radio  (alleen  E-mail  verkeer  tussen 
client  en  server). 

In  de  volgende  afbeeldingen  is  aangegeven  hoe  de  infrastructuur  te  velde 
opgebouwd  kan  zijn. 
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Figuur  3:  Infrastructuur  in  een  operationele  omgeving. 


ISIS  Configuratie: 

-  Lokaal  netwark 

•  KrachtJga  PC  servers 

-  Portable  PC  clients 


Figuur  4: 


Voorheeldopstelling  ISIS-configuratie  in  shelter. 
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3.5.2  Database 

Binnen  de  ISIS-architectuur  worden  twee  databases  onderkend: 

1.  ISIS-database. 

2.  Applicatiedatabase. 

In  de  volgende  figuur  is  de  relatie  hiertussen  schematisch  weergegeven: 


Applicaties  (o.a.  GIS) 


Replicatie 


_ _ I 

Figuur  5:  Relatie  tussen  applicatiedatabase  en  ISIS-database. 

De  ISIS-database  moet  worden  gezien  als  een  uitwisselingsdatabase  en  wordt 
gebruikt  door  het  replicatiemechanisme.  De  ISIS-database  is  afgeleid  van  het  ISIS- 
datamodel  dat  weer  is  gebaseerd  op  het  ATCCIS-datamodel.  Alleen  gegevens  die 
in  de  ISIS-database  zijn  opgenomen  kunnen  uiteindelijk  gerepliceerd  worden  naar 
andere  knooppunten. 

De  applicatiedatabase  bevat  gegevens  die  specifiek  zijn  voor  een  applicatiegroep 
(AG).  Een  applicatiegroep  kan  bijvoorbeeld  specifieke  logistieke  of  personele 
extensies  bevatten.  Randvoorwaarde  is  steeds  dat  de  applicatiedatabase  vertaalbaar 
moet  zijn  naar  ISIS.  Om  de  gegevens  van  de  applicatiedatabase  te  repliceren  van 
en  naar  andere  knooppunten  dient  er  een  vertaling  van  en  naar  de  ISIS-database 
plaats  te  vinden.  Vertaling  is  alleen  noodzakelijk  als  de  gegevens  daadwerkelijk 
via  het  replicatiemechanisme  uitgewisseld  moeten  worden  met  andere 
knooppunten.  Indien  gegevens  alleen  binnen  de  applicatiegroep  gebruikt  worden  is 
vertaling  dus  niet  noodzakelijk.  Deze  vertaling  (lees:  het  opstellen  van  de 
vertaalregels)  valt  onder  verantwoordelijkheid  van  de  ontwikkelaar  van  de 
applicatiegroep. 
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3.5.3  Replicatie 

De  ISIS-replicatieservice  zorgt  ervoor  dat  operationele  modulen  op  automatische 
wijze  onderling  operationele  informatie  kunnen  uitwisselen. 

Elk  ISIS-systeem  (zie  figuur  3)  dat  via  replicatie  gegevens  uit  wil  wisselen  treedt 
op  als  replicatieknooppunt  of  {replication)  node.  Een  node  herbergt  den  logische 
verzameling  operationele  gegevens.  Gegevensuitwisseling  vindt  plaats  tussen 
nodes. 

Een  belangrijk  concept  voor  replicatie  is  het  eigenaarschap  van  gegevens.  Elk 
gegevenselement  heeft  een  eigenaar.  Deze  representeert  de  persoon  of  instantie  die 
dat  gegevenselement  heeft  aangemaakt  en  in  beheer  heeft.  Alleen  de  eigenaar  mag 
zijn  gegevens  muteren. 

Replicatie  vindt  plaats  op  basis  van  replicatiecontracten  tussen  eigenaren  van 
gegevens;  het  initiatief  van  een  contract  ligt  bij  de  data-receiver.  Nadat  een 
knooppunt  een  replicatiecontract  heeft  afgesloten  wordt  een  kopie  van  de  gegevens 
ontvangen  (ook  wel  initiele  ‘bulk’  genoemd).  Hierbij  ontvangt  het  knooppunt 
ednmalig  een  kopie  van  alle  gegevens  die  binnen  het  contract  vallen.  De  gegevens 
worden  vanaf  dat  ogenblik  automatisch  up-to-date  gehouden.  Indien  de  verbinding 
tussen  de  knooppunten  voor  langere  tijd  wegvalt  wordt  een  incrementele  bulk 
verstuurd.  De  omvang  hiervan  is  sterk  afhankelijk  van  de  tijd  die  is  verstreken 
tussen  de  laatste  gegevensuitwisseling  en  het  aantal  mutaties  dat  in  die  tijd  heeft 
plaatsgevonden.  Bij  een  incrementele  bulk  worden  alle  uit  te  voeren  mutaties 
doorgevoerd  (geschatte  tijdsduur  ongeveer  4  minuten),  waarbij  de  volgorde  van  de 
mutaties  in  stand  gehouden  wordt.  De  betekenis  en  structuur  van  de  uit  te  wisselen 
gegevens  is  eenduidig  vastgelegd  in  het  ISIS-uitwisselmodel.  De  relatie  tussen  dit 
uitwisselmodel  en  het  datamodel  dat  door  de  applicaties  wordt  gebruikt  (het 
applicatiemodel)  is  in  de  paragraaf  database  toegelicht. 

In  een  replicatiecontract  wordt  niet  alleen  vastgelegd  met  wie  gegevens 
uitgewisseld  worden,  maar  ook  welke  gegevens  uitgewisseld  moeten  worden. 
Gegevens  kunnen  geselecteerd  worden  op  basis  van  gegevenstype  (entiteit, 
attribuut)  en  gegevensinstantie  (record).  Op  basis  hiervan  kunnen  in  de  toekomst 
complexe  filters  gedefinieerd  worden.  Een  voorbeeld  hiervan  is:  ‘Stuur  mij  de 
status  en  positie  van  alle  gewapende  vijandelijk  eenheden  van  brigadeniveau  en 
hoger  die  binnen  gebied  alfa  zijn  waargenomen  ’. 

Replicatie  werkt  over  diverse  communicatieprotocollen,  onder  de  voorwaarde  dat 
het  wordt  ondersteund  door  een  berichtensysteem  dat  via  MAPI  (Mail  Application 
Programming  Interface)  aangestuurd  kan  worden.  Momenteel  kunnen  berichten 
ook  rechtstreeks  via  TCP/IP  worden  verstuurd.  Wel  geldt  dat 
communicatieprotocol  en  -medium  -  met  name  de  beschikbare  bandbreedte  -  van 
invloed  zijn  op  de  uiteindelijke  performance. 
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Replicatie  van  gegevens  vindt  periodiek  plaats,  waarbij  de  periode  instelbaar  is. 
Indien  de  periode  kort  gehouden  wordt  zullen  gegevens  actueler  zijn.  Wordt  een 
langere  periode  aangehouden,  dan  zal  het  uitgaande  replicatieproces,  met  name  bij 
complexe  filters,  in  het  algemeen  efficienter  verlopen.  Momenteel  wordt  als 
uitgangspunt  gebruikt  dat  gemuteerde  gegevens  binnen  10  minuten  in  de  database 
bij  de  abonnees  aanwezig  moeten  zijn.  Hierbij  wordt  er  al  van  uitgegaan  dat  er 
gebruik  wordt  gemaakt  van  filtering.  Indien  geen  gebruik  wordt  gemaakt  van 
filtering  kunnen  gegevens  direct  worden  verstuurd. 

Hoewel  de  mogelijkheid  van  filtering  is  ingebouwd  worden  replicatiecontracten 
momenteel  nog  niet  van  filters  voorzien;  voor  divisie-  en  brigadeniveau  is 
voldoende  bandbreedte  beschikbaar.  Een  contract  wordt  momenteel  aangegaan 
voor  alle  gegevens  van  een  bepaalde  gebruiker. 

3.5.4  GIS-applicatie 

Binnen  ISIS  zijn  momenteel  twee  (gebruikers)applicaties  ontwikkeld  op  basis  van 
het  ISIS  framework;  de  GIS-applicatie  en  de  ORBAT-browser.  Beide  applicaties 
bieden  basisfunctionaliteit  om  militaire  objecten  te  manipuleren. 

De  GIS-applicatie  biedt  de  C2-functionaliteit  om  eenheden  en  andere  militaire 
objecten  en  symbolen  te  manipuleren  op  een  geogrcifische  achtergrond  door 
gebruik  te  maken  van  overlays  (oleaten  of  transparanten).  De  GIS-applicatie  werkt 
op  de  applicatiedatabase  (zie  paragraaf  Database).  Hiervoor  is  een  verbinding  met 
de  server  noodzakelijk. 

Als  de  gebruiker  door  het  systeem  geautoriseerd  is  krijgt  deze  toegang  tot  de 
applicatie.  De  autorisatie  vindt  in  principe  transparant  plaats  en  is  gekoppeld  aan 
de  gebruikersverificatie  die  plaats  vindt  bij  het  inloggen  op  het  systeem.  Met  de 
autorisatie  is  tevens  het  eigenaarschap  vastgelegd:  een  gebruiker  mag  alleen  die 
objecten  manipuleren  waarvan  hij  de  eigenaar  is.  Wei  kan  van  alle  gepresenteerde 
objecten  informatie  worden  opgevraagd. 

Vervolgens  worden  een  of  meer  overlays  aangemaakt  waarop  de  gegevens 
gepresenteerd  worden.  Afhankelijk  van  het  filter  dat  de  gebruiker  heeft 
gedefmieerd  wordt  bepaald  welke  gegevens  op  het  overlay  worden  afgebeeld. 
Filters  geven  tot  in  detail  aan  of  een  eenheid  afhankelijk  van  het  type,  de 
operationele  status  of  andere  specifieke  kenmerken  op  het  overlay  afgebeeld  moet 
worden.  Dit  geldt  ook  voor  gebieds-,  lijn-  en  puntobjecten. 

Het  toevoegen  van  objecten  aan  het  GIS  vindt  plaats  door  selectie  uit 
keuzeschermen.  Voor  eenheden  is  een  'pick-list'  beschikbaar  met 
voorgedefinieerde  typen  eenheden. 
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Overlays  kunnen  in  twee  groepen  ingedeeld  worden: 

1.  Actuele  overlays. 

2.  Plan  overlays. 

In  het  actuele  overlay  wordt  de  huidige  situatie  getoond.  Indien  modificaties  in  de 
database  worden  aangebracht  die  de  huidige  situatie  beinvloeden  zullen  andere 
gebruikers  direct  genotificeerd  worden  van  de  wijziging.  De  gebruiker  kan  zelf 
aangeven  of,  en  zo  ja  op  welke  manier,  de  notificatie  moet  plaatsvinden.  Nadat  de 
wijziging  is  doorgevoerd,  zijn  de  actuele  gegevens  voor  de  gebruiker  beschikbaar. 
Wijzigingen  kunnen  afkomstig  zijn  van  applicaties  op  hetzelfde  knooppunt 
(lokaal)  of  via  replicatie  afkomstig  zijn  van  andere  knooppunten. 

Het  plan  overlay  wordt  gebruikt  voor  het  specificeren  van  plannen.  Bij  het 
ontwikkelen  van  een  plan  kan  de  actuele  situatie  als  uitgangspunt  worden  gebruikt. 
Ook  kan  gekozen  worden  voor  het  ‘van  de  grond  af  opbouwen  van  een  plan. 
Eenheden,  gebieden,  lijnen  en  punten  kunnen  vervolgens  gemanipuleerd  worden 
om  het  plan  gestalte  te  geven.  Het  overlay  kan,  al  dan  niet  met  geografische 
achtergrond  afgedrukt  worden. 

Doordat  het  plan  net  als  de  actuele  situatie  op  een  overlay  kan  worden  afgebeeld  is 
de  relatie  tussen  de  actuele  situatie  en  het  plan  eenvoudig  te  visualiseren.  De  op 
het  plan  overlay  afgebeelde  phn-objecten  hebben  echter  geen  directe  relatie  met 
de  actuele  objecten. 

Binnen  de  GIS  applicatie  is  functionaliteit  aanwezig  om  de  (lineaire)  afstand  van 
een  opgegeven  route  te  bepalen.  Momenteel  is  geen  geografische  informatie 
opgenomen  in  het  kaartmateriaal  (hoogte- informatie  en  terreinobjecten).  In  de 
toekomst  kunnen  dergelijke  gegevens  in  de  vorm  van  overlays  gerepresenteerd 
worden. 

De  GIS-applicatie  is  opgebouwd  uit  herbruikbare  componenten  (het  zogenoemde 
framework).  Onderdelen  hiervan  kunnen  ook  toegepast  worden  bij  de 
ontwikkeling  van  andere  applicaties.  Daamaast  kan  de  functionaliteit  van  het  GIS 
uitgebreid  worden  door  gebruik  te  maken  van  zogenoemde  add-ins.  Op  deze  wijze 
kunnen  onder  andere  overlays  met  een  complexe  functionaliteit  (bijvoorbeeld 
logistieke  planning  of  wargaming)  binnen  het  GIS  gebruikt  worden. 

Voor  wat  betreft  de  gebruikersinterface  voldoet  de  GIS-applicatie  aan  de 
Windows’ 95  Style  Guide.  In  de  volgende  figuur  is  een  schermafdruk  gegeven  van 
de  GIS-applicatie. 
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Figuur  6:  GIS-applicatie,  met  notificaties  van  verplaatsingen. 


3.5.4.1  HEROS  interface 

HEROS  (Heeres-  Fiihrungsinformationssystem  fiir  Operationsfiihrung  in  Staben)  is 
het  Duitse  commandovoeringssysteem  dat  wordt  gebruikt  in  de  staven  op 
legerkorps  niveau. 

Om  de  informatieflow  tussen  het  Nederlandse  (ATCCIS  gebaseerd)  en  het  Duitse 
(ADatP-3  gebaseerd)  gedeelte  van  het  l(GE/NL)Corps  in  staat  te  stellen  gegevens 
uit  te  wisselen  is  de  HEROS  gateway  ontwikkeld.  Deze  gateway  converteert 
ADatP-3  berichten  naar  ATCCIS/ISIS  gegevens  en  viceversa.  Op  deze  manier 
kunnen  situation  reports  afgebeeld  worden  binnen  de  GIS  applieatie.  De  HEROS 
gateway  is  ontwikkeld  met  behulp  van  het  Framework  en  als  add-in  beschikbaar  in 
het  ISIS-GIS.  De  ADatP-3  berichten  kunnen  ook  met  behulp  van  een  template 
worden  ingevoerd. 
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3.5.5  ORBAT-browser 

De  ORBAT-browser  geeft  een  grafisch  overzicht  van  de  organisatiestructuur  van 
militaire  eenheden. 


Binnen  de  ORBAT-browser  kunnen  diverse  typen  relaties  gevisualiseerd  worden 
(bijv.  full  command,  operational  command  en  tactical  command). 
Onderbevelstellingen  kunnen  met  behulp  van  drag-and-drop  uitgevoerd  worden. 
Ook  eigenschappen  van  eenheden  kunnen  geraadpleegd  en  -  mits  de  gebruiker  de 
juiste  bevoegdheden  heeft  -  aangepast  worden. 

Voor  wat  betreft  autorisatie  en  eigenaarschap  gelden  dezelfde  regels  als  bij  de  GIS- 
applicatie.  In  de  ORBAT-browser  is  het  ook  mogelijk  geplande 
organisatiestructuren  vast  te  leggen. 


De  ORBAT-browser  gebruikt  gegevens  uit  de  applicatie  database;  een  verbinding 
met  de  server  is  dus  noodzakelijk.  De  gebruikersinterface  van  de  ORBAT-browser 
sluit  aan  bij  die  van  het  GIS  en  voldoet  aan  de  Windows’ 95  Style  Guide. 
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Figuur  7:  ORBAT-browser 


3.5.6  Office  Applicaties 

Het  besluitvormings-  en  bevelvoeringsproces  omvat  veel  activiteiten  die  met 
behulp  van  kantoortoepassingen  goed  ondersteund  kunnen  worden.  Elke  ISIS-client 
is  daarom  uitgerust  met  de  complete  Microsoft  Office  omgeving.  Dit  omvat: 
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1 .  Word  (tekstverwerker) . 

2.  Excel  (spreadsheet). 

3 .  PowerPoint  (presentatiehulpmiddel) . 

4.  Access  (database). 

5.  Schedule  (elektronische  agenda). 

De  applicaties  vormen  een  geintegreerde  omgeving  en  dekken  een  groot  deel  van 
de  kantoortoepassingen  af.  De  GIS-applicatie  en  de  ORBAT-browser  sluiten  voor 
wat  betreft  bediening  en  interface  aan  bij  de  kantoortoepassingen. 

Naast  Office  is  de  complete  Windows’ 95  omgeving  beschikbaar  op  elke  client. 
Hiervan  kan  ook  gebruik  worden  gemaakt  als  de  client  niet  verbonden  is  met  een 
server. 

3,5,7  Exchange  en  formeel  berichtenverkeer 

Exchange  is  een  systeem  dat  E-mail  verkeer  mogelijk  maakt  tussen  twee 

gebruikers.  Exchange  is  opgebouwd  uit  twee  delen: 

1.  Exchange  Server,  aanwezig  op  de  server. 

2.  Exchange  Client,  aanwezig  op  elke  client  die  over  mailfaciliteiten  moet 
kunnen  beschikken. 

Exchange  wordt  gebruikt  om  gegevens  lokaal  of  met  andere  knooppunten  uit  te 
wisselen  die  niet  in  de  database  worden  opgenomen.  Hierbij  kunnen  ook  Office 
onderdelen  in  het  bericht  worden  opgenomen  (bijv.  een  spreadsheet).  Exchange 
wordt  ook  gebruikt  door  het  Tactical  Message  System  en  het  replicatiemechanisme 
om  gegevens  tussen  twee  knooppunten  (via  ZODIAC  of  ethemet)  uit  te  wisselen. 

Formeel  berichtenverkeer:  Tactical  Message  System  (TMS) 

TMS  is  een  volledig  geautomatiseerd  systeem  voor  formeel  berichtenverkeer. 
Gestructureerde  berichten  worden  hiermee  opgesteld,  verzonden  en  ontvangen. 
Voor  de  distributie  wordt  gebruik  gemaakt  van  de  ISIS  infrastructuur.  Archivering 
vindt  automatisch  plaats.  TMS  vervangt  de  ABDIS  systemen  en  is  primair 
ontwikkeld  voor  gebruik  ‘te  velde*.  TMS  ondersteunt  het  zogenoemde  ‘ACP  - 
RCP  concept’.  Hierbij  vervullen  Commandoposten  afwisselend  de  rol  van  Actieve 
Commandopost  (ACP)  en  Reserve  Commandopost  (RCP).  De  rol  die  een 
Commandopost  vervult  is  echter  transparant  voor  de  gebruiker  van  TMS. 

A1  naar  gelang  het  onderwerp  van  een  militair  bericht  worden  een  of  meer 
zogenoemde  Subject  Identifier  Codes  (SIC’s)  aan  het  bericht  toegekend. 
Gebruikers  kunnen  zich  abonneren  op  specifieke  SIC’s.  De  distributie  binnen  een 
eenheid  is  afhankelijk  van  de  geldende  abonnementen.  De  (afhandel)status  van  de 
berichten  kan  door  de  gebruikers  gevolgd  worden. 
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Informed  berichtenverkeer:  Exchange 

Voor  het  versturen  van  informele  berichten  wordt  Exchange  client  gebruikt. 
Exchange  maakt  ook  gebruik  van  de  ISIS-datacommunicatie  infrastructuur.  E-mail 
verkeer  is  mogelijk  binnen  een  operationele  module  en  tussen  operationele 
modulen.  Voor  de  fysieke  distributie  te  velde  wordt  gebruik  gemaakt  van  onder 
andere  ZODIAC  (server-server)  en  FM-90(X)  (client-server). 


4.  TICCS  op  brigade-  en  divisieniveau 

4.1  Inleiding 

De  opbouw  van  het  Target  Information  Command  and  Control  System  (TICCS)  is 
in  onderstaande  figuur  weergegeven: 


Figuur  8:  De  TICCS  componenten  met  omcirkeld  de  C2-bovenlaag. 

Een  van  de  componenten  is  de  zogenoemde  C2-bovenlaag  (in  bovenstaande  figuur 
omcirkeld  weergegeven).  Deze  component  omvat  Command  &  Control 
functionaliteit  op  divisie-  en  brigadeniveau.  Binnen  de  C2-bovenlaag  worden  de 
volgende  vier  modulen  onderscheiden: 

1.  Airspace  Control  (ASC). 

2.  Besluitvorming  en  bevelvoering. 

3.  Overige  besturingsprocessen. 

4.  Ondersteunende  processen. 

Het  document  TICCS,  Een  beschrijving  in  modules’  [3]  gaat  in  op  de 
functionaliteit  van  de  genoemde  modulen  en  de  daaraan  te  stellen  eisen;  het 
document  ‘Informatieanalyse  TICCS:  Het  lua  proces’  [4]  beschrijft  de  processen  en 
bijbehorende  gegevensstromen. 
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Voor  wat  betreft  de  niveaus  waarop  deze  processen  zich  afspelen  wordt 
onderscheid  gemaakt  tussen  de  C2-bovenlaag  (divisie-  en  brigadeniveau)  en  de  C2- 
onderlaag  (batterij  tot  en  met  wapensysteem). 

Dit  hoofdstuk  beschrijft  eerst  de  context  van  het  Target  Information  Command  and 
Control  Systeem  door  in  te  gaan  op  de  organisatie  en  inzetmogelijkheden. 
Vervolgens  wordt  ingegaan  op  de  functionaliteit  van  de  genoemde  processen  en 
wordt  kort  ingegaan  op  interfaces. 

Voor  een  meer  gedetailleerde  beschrijving  van  de  genoemde  processen  wordt 
verwezen  naar  [1 1]  en  [12]. 


4.2  Organisatie 

In  deze  paragraaf  is  de  organisatiestructuur  voor  zover  deze  voor  de  lua  op 
divisie-  en  brigadeniveau  van  belang  is  weergegeven. 

De  primaire  taak  van  de  KL  luchtverdediging  is  het  leveren  van 
gevechtsondersteuning  in  de  vorm  van  gebieds-  of  puntverdediging:  de  verdediging 
van  eenheden  of  delen  ervan,  gebieden  en  objecten  die  door  de  tactische 
commandant  als  luchtverdedigingsprioriteit  zijn  aangemerkt.  De  tweede  taak  van 
de  KL  luchtverdediging  is  het  afbreuk  doen  aan  het  vijandelijk  luchtpotentieel 
vanuit  de  voor  het  uitvoeren  van  de  primaire  taak  ingenomen  opstellingen. 

In  het  kader  van  de  nieuwe  taakstelling  van  de  KL  moet  de  KL 
luchtverdedigingsorganisatie  tevens  in  staat  zijn  om  onder  alle  omstandigheden  en 
tegen  elke  willekeurige  luchtdreiging  een  gecoordineerde  luchtverdediging  te 
kunnen  realiseren,  waarbij  ervan  uitgegaan  moet  worden  dat  het  optreden  van  de 
KL  luchtverdediging  altijd  joint  en/of  combined  zal  zijn.  Dit  vergt  een  flexibele 
organisatie  die  per  opdracht  op  eenvoudige  wijze  ‘tailor  made’  samengesteld  kan 
worden. 

De  gevechtskracht  van  de  KL  is  gegroepeerd  in  de  1(NL)  Divisie  en  deze  divisie 
maakt  deel  uit  van  het  IGNC  (German  Netherlands  Corps).  In  oorlogstijd  is  de  KL 
luchtverdediging  volledig  geintegreerd  in  de  organisatie  van  de  1(NL)  Divisie  en 
bestaat  uit: 

Divisie: 

•  2  X  gevechtsstaven 

•  2  X  TICCS-radargroep 

•  5  X  pantserluchtdoelartillerie  peloton 

•  I  X  SHORAD  peloton 

•  3  X  luchtdoelartillerie  peloton  bestaande  uit  drie  vuureenheden 
Brigade: 
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Brigade: 

•  2  X  gevechtsstaf 

•  2  X  TlCCS-radargroep 

•  5  X  pantserluchtdoelartillerie  peloton 

•  lx  SHORAD  peloton 

•  lx  luchtdoelartillerie  peloton 

De  divisie  luchtverdedigingseenheid  treedt  op  in  het  divisie  achtergebied  en  is  daar 
verantwoordelijk  voor  het  beveiligen  van  minmaal  2  divisie  objecten  (logistieke 
installaties  en/of  essentiele  infrastructuur)  en  de  divisie  reserve.  De  commandant 
van  de  divisie  luchtverdedigingseenheid  is  verantwoordelijk  voor  de 
luchtverdediging  in  het  gehele  divisie  achtergebied.  Deze  luchtverdedigingstaak 
wordt  onder  leiding  van  de  divisie  luchtverdedigingscommandant  uitgevoerd  met 
alle  in  het  divisie  achtergebied  beschikbare  luchtverdedigingsmiddelen,  inclusief 
de  daar  aanwezig  brigade  luchtverdedigingseenheid.  De  brigade 
luchtverdedigingseenheid  treedt  op  in  het  vak  van  de  voorbrigades  en  beveiligt 
daar  de  eenheden  of  delen  ervan,  gebieden  en  objecten  die  door  de  tactische 
commandant  als  luchtverdedigingsprioriteit  zijn  aangemerkt.  Indien  noodzakelijk 
voor  de  uitvoering  van  de  opdracht  kan  de  brigade  luchtverdedigingseenheid 
versterkt  worden  met  pantserluchtdoelartillerie  pelotons  en  bevelvoeringscapaciteit 
van  de  divisie  luchtverdedigingseenheid. 


4.3  Inzetmogelijkheden 

Er  zijn  drie  mogelijke  configuraties  waarin  opgetreden  kan  worden: 

1.  Vredessituatie. 

In  vredessituatie  is  er  altijd  een  beperkte  bezetting  ten  opzichte  van  de 
organieke  sterkte. 

2.  Crisisbeheersingssituatie. 

In  crisisbeheersingssituaties  is  altijd  onduidelijk  in  welke  organisatiestructuur 
opgetreden  gaat  worden.  De  kleinste  organieke  elementen  die  uitgezonden 
worden  zijn  een  of  meer  pelotons  met  daarboven  een  batterij.  De 
pelotonssamenstelling  van  de  batterij  kan  per  crisisbeheersingssituatie 
verschillen. 

3.  Oorlogssituatie. 

In  oorlogssituatie  is  de  bezetting  volgens  de  organieke  sterkte. 

Het  optreden  van  de  lua  zal  zich  in  de  toekomst  steeds  meer  kenmerken  door 
toenemende  flexibiliteit,  mobiliteit  en  interoperabiliteit,  zowel  joint  (met  andere 
krijgsmachtdelen)  als  combined  (met  buitenlandse  eenheden).  TICCS  dient  hierop 
te  anticiperen  en  ook  in  een  dergelijke  omgeving  te  voldoen  aan  de  in  hoofdstuk  2 
genoemde  doelstelling. 
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4.4  Functionele  modulen 

In  deze  paragraaf  wordt  een  kort  overzicht  gegeven  van  de  functionaliteit  die 
binnen  de  TICCS  C2-bovenlaag  is  gewenst.  De  volgende  soorten  functionele 
modulen  worden  onderscheiden  (zie  ook  figuur  8): 

1.  Airspace  Control. 

2.  Bevelvoering  en  Besluitvorming. 

3.  Overige  Besturingsprocessen. 

4.  Ondersteunende  processen 

Vee!  functionaliteit  komt  in  een  aantal  modulen  terug;  ook  is  er  niet  altijd  een 
strikte  scheiding  aan  te  geven  tot  welke  categorie  een  bepaalde  functionaliteit 
behoort.  In  dergelijke  gevallen  is  de  functionaliteit  in  ^en  van  de  desbetreffende 
categorieen  ondergebracht. 

4.4.1  Airspace  Control 

Airspace  Control  (ASC)  is  het  systeem  dat,  binnen  het  kader  van  de  door  het 
Airspace  Management  (ASM)  genomen  beslissingen  en  vastgestelde  prioriteiten 
de  regels  vaststelt  voor  het  gebruik  van  het  luchtruim  boven  de  gevechtszone. 
Hierbij  dient  het  risico  voor  het  eigen  vliegverkeer  zoveel  mogelijk  te  worden 
beperkt  en  dienen  gelijktijdig  aan  de  luchtverdedigingsmiddelen  zo  weinig 
mogelijk  beperkingen  te  worden  opgelegd. 

Het  principe  van  ASC  wordt  bepaald  door  het  in  tijd  en  ruimte  scheiden  van  het 
vliegverkeer  en  de  luchtverdedigingsmiddelen.  Het  ASC  kent  hiervoor  twee  typen 
gestandaardiseerde  berichten: 

1.  Airspace  Control  Order  (ACO) 

ACO’s  geven  bindende  regels  voor  het  gebruik  van  het  luchtruim  in  een 
bepaald  gebied  gedurende  een  bepaalde  periode. 

2.  Airspace  Control  Means  Request  (ACM-request) 

ACM-requests  worden  gebruikt  om  wensen  met  betrekking  tot  het  gebruik  van 
het  luchtruim  voor  de  komende  ASC-periode  aan  te  vragen  aan  het  naasthogere 
niveau.  ACM-requests  worden  periodiek  opgesteld  door  het  BAME  (Brigade 
Airspace  Management  Element)  en/of  DAME  (Divisie  Airspace  Management 
Element)  en  nadat  de  behoeften  aan  ASC  regelingen  van  de 
ondercommandanten  zijn  verzameld  (voor  divisie)  en  de  totale  behoefte  aan 
ASC  regelingen  is  vastgesteld. 

y\CM-requests  worden  op  meerdere  niveaus  opgesteld  en  verzonden,  ze  worden 
ingediend  door  het  legerkorps,  commandant  achtergebied  (COA),  Divisie  en 
Brigade  bij  het  naasthogere  niveau.  Het  Divisie-  en  Brigade  ACM-request  wordt 
verzonden  naar  het  naasthogere  niveau  en  tevens  naar  de  ondercommandanten.  Het 
legerkorps  ACM-request  wordt  verzonden  naar  een  hoger  niveau  (AIRCENT)  en 
tevens  als  informatie  naar  divisies,  commandant  achtergebied  en  tactische 
helikoptergroep  (THG),  en  andere  belanghebbende  ondercommandanten. 
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De  legerkorps  ACO  wordt  door  de  sectie  ASC  van  het  legerkorps  verzonden  aan 
alle  onder  bevel  staande  divisies. 

Op  divisie-  en  brigadeniveau  worden  ASC  gegevens  ingevoerd  om  bekendgesteld 
te  worden  aan  onderliggende  eenheden.  Aan  de  ASC  maatregelen  is  een  bepaalde 
geldigheidsduur  gekoppeld.  Nog  voordat  een  ASC  maatregel  actief  wordt  moeten 
de  gerelateerde  gegevens  gedistribueerd  zijn.  Op  het  ogenblik  dat  de  ASC 
maatregel  van  kracht  wordt  moet  de  gebraiker  hiervan  in  kennis  gesteld  worden. 
Dit  geldt  ook  voor  de  einde  geldigheid  van  de  maatregel  of  als  de  maatregel 
wijzigt.  Elke  ASC  maatregel  wordt  door  middel  van  een  kennisgeving  van 
ontvangst  (kvo)  bevestigd. 

4.4.2  Besluitvorming  en  bevelvoering 

Voor  zowel  het  besluitvormingsproces  als  het  bevelvoeringsproces  is 
informatievoorziening  van  essentieel  belang.  In  de  paragraaf  ‘overige 
besturingsprocessen’  wordt  hier  verder  op  ingegaan. 

De  besluitvorming-  en  bevelvoeringsprocessen  zijn  zeer  beknopt  beschreven.  Het 
gaat  hier  vooral  om  de  gegevenselementen  of  -stromen  die  met  behulp  van  een 
geautomatiseerd  systeem  ondersteund  kunnen  worden.  Deze  zijn  steeds 
schuingedrukt.  In  hoofdstuk  5  wordt  de  te  bieden  functionaliteit  voor  de  lua  in 
meer  detail  beschreven. 

Besluitvorming 

Het  besluitvormingsproces  omvat  de  stappen  om  van  een  opdracht  te  komen  tot 
een  besluit.  Op  divisie-  en  brigadeniveau  betekent  dit  dat  uitvoering  wordt  gegeven 
aan  het  Operationeel  Besluitvormings  Proces  (OPB).  Voor  meer  informatie  over 
het  OBP  wordt  verwezen  naar  [1]. 

Nadat  de  opdracht  ontvangen  of  geformuleerd  is  vindt  er  een  analyse  van  de 
opdracht  plaats.  Vervolgens  worden  richtlijnen  van  de  commandant  in 
beschouwing  genomen;  deze  kunnen  het  besluitvormingsproces  verder  sturen. 
Mede  op  grond  van  recente  gegevens  uit  het  informatievoorzieningsproces  (o.a. 
actuele  status  en  posities  van  eigen  en  vijandelijke  eenheden)  worden  er  Eigen 
Mogelijkheden  (EMn)  ontwikkeld  en  in  de  volgende  stap  wordt  het  aantal 
mogelijkheden  zoveel  mogelijk  ingeperkt. 

De  overgebleven  mogelijkheden  worden  geanalyseerd  (Operatic  Analyse). 
Factoren  die  hierin  meegenomen  worden  zijn  de  door  de  sectie  G2/G3  ontwikkelde 
Vijandelijke  Mogelijkheden  (VMn)  en  een  geactualiseerde  evaluatie  van  de 
factoren  van  invloed.  Doel  is  te  komen  tot  een  eigen  mogelijkheid. 

•  Er  worden  beslispunten  vastgesteld,  gerelateerd  aan  geografische  locaties 
(hierin  worden  resultaten  van  verkenningen  meegenomen  en  factoren  zoals 
terrein  en  weer).  Het  resultaat  wordt  vastgelegd  in  een 
Beslissingsondersteunend  Oleaat  (BO). 
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•  Er  worden  eventualiteitenplannen  vastgesteld  die  de  staf  nog  verder  moet 
uitwerken. 

•  Er  wordt  een  operatiebevel  en  een  synchronisatiematrix  (SM)  gemaakt  om  de 
commandant  te  ondersteunen  bij  het  nemen  van  beslissingen  gedurende  de 
uitvoering  van  de  militaire  operatie. 

De  commandant  kiest  een  Eigen  Mogelijkheid  en  geeft  deze  door  als  zijn  besluit. 
Dit  wordt  in  het  bevel  opgenomen  en  gedistribueerd. 

Bevelvoering 

De  bevelvoering  moet  leiding  geven  aan  de  uitvoering  van  de  gegeven  opdrachten, 
zowel  tijdens  de  voorbereiding  als  tijdens  het  daadwerkelijke  gevecht. 
Bevelvoering  bestaat  uit  dirigeren,  controleren  en  bijsturen.  Voor  bevelvoering  is 
actuele  informatievoorziening  van  essentieel  belang. 

In  de  praktijk  houdt  dit  in  dat  (diverse  typen)  opdrachten  en  bevelen  samengesteld 
en  gedistribueerd  worden  en  dat  controle  plaatsvindt  door  het  monitoren  van  de 
actuele  situatie  en  het  ontvangen  van  rapportages  en  meldingen. 

4.4.3  Overige  besturingsprocessen 

Onder  overige  besUiringsprocessen  vallen  het  informatieverwervingsproces  en  het 
vuurleidingsproces.  Op  brigade-  en  divisieniveau  is  het 

informatieverwervingsproces  van  belang.  Dit  proces  voorziet  de  brigade  en  divisie 
van  essentiele  actuele  gegevens  die  besluitvorming  en  bevelvoering  mogelijk 
maken.  Het  vuurleidingsproces  speelt  zich  geheel  op  wapensysteemniveau  af  en 
valt  daarmee  buiten  de  context  van  dit  onderzoek. 

Voor  de  informatievoorziening  van  de  divisie  en  brigade  zijn  diverse  soorten 
rapportages  en  meldingen  van  belang.  De  rapportages  en  meldingen  kunnen  zowel 
van  hetzelfde  niveau  als  van  een  lager  /  hoger  niveau  afkomstig  zijn.  In  hoofdstuk 
5  wordt  hier  dieper  op  ingegaan. 

De  brigade  ontvangt  ook  het  luchtbeeld  dat  afkomstig  is  van  de  TICCS-sensoren. 
Deze  gegevens  worden  ‘near-realtime’  ontvangen. 

Op  brigade-  en  divisieniveau  dient  men  inzicht  te  hebben  in  de  ontplooiing  van  de 
luchtverdediging  (zowel  van  de  eenheden  onder  bevel  als  van  de  eenheden  in 
hetzelfde  gebied).  Het  gaat  hierbij  met  name  om  de  actuele  locaties  van  sensoren, 
eenheden  en  commandoposten  die  aan  de  hogere  niveaus  dienen  te  worden 
doorgegeven  door  middel  van  rapportages. 

4.4.4  Ondersteunende  processen 

De  ondersteunende  processen  zorgen  ervoor  dat  het  vuurleidingsproces  over 
voldoende  middelen  beschikt  om  de  opgedragen  taak  te  kunnen  uitvoeren. 
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Op  brigadeniveau  is  hierbij  het  materieelverzorgingsproces  van  belang.  Uit  te 
voeren  activiteiten  zijn  het  onderhouden,  herstellen  en  vervangen  van  materieel  dat 
nodig  is  voor  het  primaire  proces. 


4.5  Interfaces  met  derden 

4.5.1  Target  Information 

De  interfaces  met  andere  systemen  bevinden  zich  grotendeels  binnen  de  Target 
Information  (TI)  component.  Het  betreft  hier  het  uitwisselen  van 
iuchtbeeldinformatie.  Systemen  die  deze  informatie  aan  kunnen  leveren  zijn: 

•  Low  Level  Air  Picture  Interface  (LLAPl): 

*  Heeres  Flugabwehr  Aufklarungs-  und  FuhrungsSystem  (HFlaAFuSys)  van 
het  Duitse  Legerkorps. 

*  Forward  Area  Air  Defence  C3  System  van  de  USA  (FAAD/C3). 

*  Air  Defence  Command  and  Information  System  van  de  UK  (ADCIS). 

•  Klu/AWACS. 

De  informatie  wordt  aan  de  TICCS  Luchtbeeld-opbouw  component  aangeleverd. 
Afhankelijk  van  bepaalde  eigenschappen  van  de  aangeleverde  doelinformatie 
worden  de  gegevens  al  dan  niet  verstuurd  als  trackbericht. 

4.5.2  Command  and  Control 

Voor  wat  betreft  Command  en  Control  is  momenteel  alleen  de  interface  met  het 
Duitse  HEROS  van  belang.  HEROS  (Heeres-  Fuhrungsinformationssystem  fiir 
Operationsfiihrung  in  Staben)  is  gebaseerd  op  het  ADatP-3  berichten-formaat.  Het 
systeem  ondersteunt  de  commandovoering  van  de  staven  van  de  Duitse 
landstrijdkrachten. 

De  lua  maakt  altijd  onderdeel  uit  van  grotere  formaties  (andersoortige  eenheden). 
De  lua  is  daarmee  afhankelijk  van  de  informatie  die  door  andere  onderdelen  wordt 
aangeleverd  (bijv.  Meteo  van  de  Artillerie  Ondersteunings  Batterij  (VUIST)  en 
Commandovoeringsgegevens  afkomstig  van  de  manoeuvre).  Ook  wordt  informatie 
door  de  lua  aangeleverd  aan  andere  onderdelen. 
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5.  TICCS-  versus  ISIS-gegevens 


Het  ISIS  gegevensmodel  is  ontwikkeld  om  de  kem  van  de  Conunand  &  Control 
activiteiten  op  brigade-  en  divisieniveau  af  te  dekken.  Specifieke  deelgebieden 
zoals  vuursteun,  luchtverdediging  en  logistiek  zijn  hierin  niet  opgenomen.  Om 
deze  deelgebieden  toch  in  staat  te  stellen  gegevens  met  andere  knooppunten  uit  te 
wisselen,  is  het  noodzakelijk  dat  de  gegevens  worden  opgenomen  in  het  ISIS- 
uitwisselmodel. 

De  WBU  heeft  de  TICCS  gegevensbehoefte  in  kaart  gebracht.  Hierbij  is  ervoor 
gekozen  de  gegevensmodellering  uit  te  voeren  zonder  uit  te  gaan  van  de  ISIS- 
gegevensstructuur.  Dit  heeft  geresulteerd  in  het  TICCS  datamodel  [11]. 

Binnen  ISIS  wordt  momenteel  versie  1.20  van  het  datamodel  gebruikt  (zie  ook 
[8]).  Het  ISIS-datamodel  is  afgeleid  van  het  ATCCIS-datamodel  (zie  ook  [13]). 
Versie  1.20  van  het  ISIS-datamodel  is  gebruikt  als  uitwisselmodel  (zie  ook 
hoofdstuk  3  paragraaf  5).  Het  ISIS-applicatiemodel  bevat  slechts  een  gedeelte  van 
het  complete  uitwisselmodel.  De  structuur  is  zodanig  van  opzet  dat  de  huidige 
applicaties  op  een  eenvoudige  wijze  toegang  kunnen  krijgen  tot  de  C2-gegevens. 

In  dit  hoofdstuk  wordt  uitgegaan  van  het  ISIS-datamodel  versie  1.20  en  van  het 
TICCS-datamodel. 

De  doelstelling  van  dit  hoofdstuk  is: 

•  Inzicht  geven  in  de  verschillen  tussen  de  gegevensbehoefte  van  TICCS  en 
datgene  wat  het  ISIS-datamodel  te  bieden  heeft. 

•  Bij  de  probleemgebieden  aan  te  geven  hoe  de  gegevens  wel  in  het  ISIS- 
datamodel  opgenomen  kunnen  worden. 

•  Aangeven  waar  significante  verschillen  aanwezig  zijn  tussen  het  ISIS- 
applicatiemodel  en  het  ISIS-datamodel. 

Er  wordt  met  nadruk  op  gewezen  dat  hier  wordt  uitgegaan  van  de 
gegevensstructuur  in  het  ISIS-datamodel;  dit  hoeft  niet  te  betekenen  dat  er  ook 
applicaties  aanwezig  zijn  om  de  hierin  aanwezige  gegevens  te  manipuleren. 

In  dit  hoofdstuk  wordt  het  volgende  verondersteld: 

•  De  lezer  is  bekend  met  het  ISIS-datamodel  en  de  daarin  voorkomende 
entiteiten,  attributen  en  domeinen  (zie  ook  [8]). 

•  De  lezer  is  bekend  met  het  TICCS-datamodel  en  de  daarin  voorkomende 
entiteiten,  attributen  en  domeinen  (zie  ook  [11]). 

•  De  lezer  is  bekend  met  datamodelleringstechnieken;  in  het  bijzonder  die  voor 
Entity  Relationship  Diagrams. 


TNO-rappoft 


38 


FEL-98-A245 


Indien  de  benodigde  voorkennis  niet  aanwezig  is  wordt  geadviseerd 
in  plaats  van  paragraaf  5.3  de  samenvatting  in  paragraaf  5.4  door  te  nemen. 


5.1  Het  ISIS-datamodel 

Het  ATCCIS-datamodel  is  ontwikkeld  om  Internationale  interoperabiliteit  op  het 
gebied  van  Command  &  Control  te  garanderen.  Het  ISIS-datamodel  is  afgeleid  van 
het  ATCCIS-datamodel  en  garandeert  interoperabiliteit  op  nationaal  niveau.  Het 
ISIS-datamodel  dekt  de  generieke  kern  van  de  C2-processen  op  brigade-  en 
divisieniveau  af.  Bij  het  ontwerp  van  het  ISIS-datamodel  is  er  rekening  mee 
gehouden  dat  de  gegevens  vertaalbaar  moeten  zijn  naar  ATCCIS  en  viceversa, 
zodat  compatibiliteit  gewaarborgd  blijft.  De  naamgeving  die  in  het  ISIS-datamodel 
is  gehanteerd  is  conform  de  ATCCIS  standaarden.  Het  ISIS-datamodel  dient  in  de 
toekomst  te  migreren  naar  het  KL-C2  datamodel.  Dit  datamodel  bevat  wel  de 
verschillende  functionele  gebieden. 

Hoewel  het  ISIS-datamodel  extensies  in  de  vorm  van  functionele  deelgebieden 
toelaat,  vallen  deze  niet  binnen  de  scope  van  het  ISIS-datamodel.  ISIS  stelt  dat  elk 
functioneel  deelgebied  er  zelf  zorg  voor  moet  dragen  dat  de  gegevens  die  specifiek 
zijn  voor  dat  deelgebied  vertaalbaar  zijn  naar  ISIS  en  viceversa.  Zowel  de 
uitbreiding  van  het  applicatiemodel  als  de  vertaling  van  en  naar  het  uitwisselmodel 
dienen  door  het  functionele  deelgebied  aangeleverd  te  worden.  Voor  een 
gedetailleerde  beschrijving  van  het  ISIS  datamodel  wordt  verwezen  naar  'ISIS  Data 
Model  Versie  1.20'  [8]. 


5.2  Het  TICCS-datamodel 

Het  TICCS-datamodel  is  onafhankelijk  van  ISIS  opgesteld.  Het  dekt  de 
gegevensbehoefte  af  van  wapensysteemniveau  tot  batterijniveau  (daarboven  is  een 
aantal  lua-specifieke  processen  bekeken),  voor  zover  het  de  lua  betreft.  Hieronder 
vallen  ook  gegevens  die  onderdeel  zijn  van  het  generieke  C2-proces  en  dus  door 
ISIS  afgedekt  worden.  Een  belangrijk  kenmerk  van  lua-gerelateerde  entiteiten  is 
het  gebruik  van  de  derde  dimensie.  Andere  voor  TICCS  benodigde  entiteiten  zijn 
bijvoorbeeld: 

•  Airspace  Control  Means. 

•  Airspace  Control  Orders. 

•  Lua-rapporten  en  -meldingen. 

De  volledige  documentatie  van  het  TICCS-datamodel  is  opgenomen  in  [1 1]. 
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5.3  Verschillen  TICCS  -  ISIS 

Om  TICCS  gegevens  met  andere  knooppunten  uit  te  kunnen  wisselen  is  het  nodig 
dat  de  gegevens  worden  opgenomen  in  het  ISIS-datamodel  (het  zogenoemde 
uitwisselmodel).  In  eerste  instantie  zou  de  WBU  een  vergelijk  tussen  het  ISIS-  en 
TICCS-datamodel  maken  (Compliancy  TICCS  -  ISIS).  Omdat  het  ISIS-datamodel 
momenteel  een  revisie  ondergaat  is  besloten  hiervan  af  te  zien  en  te  wachten  tot 
het  gereviseerde  datamodel  is  opgeleverd. 

Het  gevolg  hiervan  is  dat  het  compliancy  document  niet  in  dit  hoofdstuk  als 
uitgangspunt  kan  worden  gebruikt.  In  dit  hoofdstuk  wordt  daarom  de  volgende 
werkwijze  gehanteerd: 

•  Uitgegaan  wordt  van  het  ISIS-datamodel  versie  1.20  en  het  TICCS-datamodel 
concept  versie. 

•  Indien  TICCS-gegevens  zonder  meer  in  het  ISIS-datamodel  ondergebracht 
kunnen  worden  (bijvoorbeeld  de  gegevens  van  een  eenheid),  zal  hier  niet 
verder  op  worden  ingegaan. 

•  Indien  TICCS-gegevens  afgebeeld  kunnen  worden  naar  het  ISIS-datamodel 
wordt  aangegeven  op  welke  manier  dit  kan  plaatsvinden.  Indien  dit  niet  of  niet 
goed  mogelijk  is  wordt  kort  aangegeven  op  welke  punten  het  ISIS-datamodel 
aangepast  /  uitgebreid  zou  moeten  worden  om  de  TICCS  gegevens  wel  te 
kunnen  herbergen. 

Wanneer  hier  gesproken  wordt  over  het  ISIS-datamodel  wordt  bedoeld  het  ISIS- 
datamodel  versie  1.20.  Dit  model  is  gelijk  aan  het  ISIS-uitwisselmodel  dat  door  het 
replicatiemechanisme  wordt  gebruikt. 

De  voorgestelde  wijzigingen  zullen  niet  beperkt  blijven  tot  het  datamodel  alleen: 

•  Applicaties  zullen  aangepast  moeten  worden  of  ontwikkeld  moeten  worden  om 
gebruik  te  kunnen  maken  van  de  nieuwe  gegevens. 

•  De  vertaler  tussen  de  applicatie-  en  de  uitwisselingsdatabase  zal  aangepast 
moeten  worden  om  de  gegevens  uit  te  kunnen  wisselen  met  andere 
knooppunten. 

De  derde  dimensie:  (Referentie)Punten,  Lijnen  en  volumes 

•  Bij  ACM-objecten  (cirkel,  lane,  rechthoek,  veelhoek. . .)  is  in  het  ISIS’ 
datamodel  wel  de  mogelijkheid  aanwezig  om  minimale  en  maximale  hoogte  te 
specificeren  (hoewel  het  niet  mogelijk  is  om  bij  deze  minimale  en  maximale 
hoogte  op  te  geven  ten  opzichte  waarvan  deze  wordt  gespecificeerd 
(bijvoorbeeld  grond-  of  zeeniveau)).  In  het  ISIS  applicatiemodel  zijn  geen 
mogelijkheden  om  met  volumes  te  werken.  Dit  model  zal  daarom  uitgebreid 
moeten  worden. 

Alle  gegevens  waar  tot  nu  toe  bij  ISIS  mee  is  gewerkt  betroffen  twee 
dimensionale  gegevens.  TICCS  concentreert  zich  juist  op  de  derde  dimensie. 
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•  Bij  de  specificatie  van  een  lane  wordt  als  uitgangspunt  een  aantal 
gespecificeerde  referentiepunten  van  een  lijn  gebruikt.  Een  lane  heeft  een 
bepaalde  breedte,  waarbij  de  gespecificeerde  lijn  in  het  midden  van  de  lane 
ligt.  Als  gekeken  wordt  naar  de  vastlegging  van  de  lane  in  de  ISIS-database, 
zal  dit  gebeuren  door  een  polygon,  waarbij  de  omhullende  van  de  lane  wordt 
vastgelegd  (en  een  minimum-  en  maximum  hoogte).  Om  toch  een  relatie  te 
blijven  leggen  met  de  eerder  genoemde  lijnpunten  dienen  voorzieningen 
getroffen  te  worden.  Hiervoor  zou  bijvoorbeeld  gebruik  gemaakt  kunnen 
worden  van  object-item-association,  waarmee  de  twee  aan  elkaar  gekoppeld 
kunnen  worden  (uitbreiding  domeinwaarden  in  object-item-association). 

•  In  ISIS  is  er  geen  rekening  mee  gehouden  dat  ACM-objecten  opgebouwd 
worden  uit  referentiepunten  (dus  een  hergebruik  van  bestaande  punten).  Dit 
dient  voor  TICCS  wel  mogelijk  te  zijn.  Elk  punt  dient  dus  gerelateerd  te 
kunnen  worden  met  een  referentiepunt. 

Airspace  Control  (Means) 

•  Omdat  vaak  extra  attributen  nodig  zijn  bij  het  specificeren  van  ACM's,  wordt 
voorgesteld  een  extra  entiteit  AirspaceControlFeature  in  te  voeren  als 
subentiteit  van  Feature  (of  als  subentiteit  van  ControlFeature).  Hiermee 
kunnen  bijvoorbeeld  specifieke  IFF-vereisten,  de  geldende  Weapon  Control 
Status  en  de  vliegrichting  vastgelegd  worden. 

•  In  TICCS  wordt  ervan  uitgegaan  dat  van  een  Mean  de  datum-tijd-groep  begin 
en  einde  wordt  vastgelegd.  In  ISIS  gebeurt  dit  met  behulp  van  de  perception. 
Het  tijdstip  einde  geldigheid  wordt  hierbij  niet  expliciet  vastgelegd,  maar  is 
afleidbaar  uit  de  gespecificeerde  tijdsduur  (duration). 

•  De  relatie  tussen  een  Mean  en  de  eenheden  waarvoor  die  Mean  van  belang  zijn 
kunnen  (nog)  niet  in  ISIS  vastgelegd  worden.  Dit  zou  kunnen  gebeuren  met 
behulp  van  object-item-association  waarbij  de  domeinwaarden  van  object- 
item-association-category-code  uitgebreid  zal  moeten  worden. 

•  De  relatie  tussen  een  pelotonsstellinggebied  en  eenheid  kan  (nog)  niet  gelegd 
worden  in  ISIS.  Ook  hiervoor  kan  object-item-association  gebruikt  worden 
(met  een  uitbreiding  van  de  domeinwaarden).  Het  resultaat  van  de  bestrijding 
is  in  ISIS  niet  rechtstreeks  gekoppeld  aan  de  eenheid.  Overwogen  kan  worden 
om  hiervoor  gebruik  te  maken  van  de  met  Action  gerelateerde  entiteiten.  In  dat 
geval  moet  het  geheel  vanuit  een  iets  ander  gezichtspunt  gezien  worden:  Een 
eenheid  heeft  een  bepaalde  taak  die  uitgevoerd  moet  worden  (objective).  De 
eenheid  heeft  hiervoor  een  aantal  middelen  tot  zijn  beschikking  (resources). 
Gedurende  de  uitvoering  van  de  taak  (en  na  afloop  hiervan)  kan  dan 
vastgelegd  worden  wat  de  resultaten  van  de  bestrijding  zijn  (task-status  en 
action-effect).  Binnen  het  ISIS-datamodel  zijn  alle  entiteiten  aanwezig  om 
actie  gerelateerde  gegevens  vast  te  leggen.  Door  gebruik  te  maken  van  de 
Action  constructie  kan  bijvoorbeeld  het  volgende  vastgelegd  worden: 

Huidige  opdracht  van  de  eenheid. 

Geplande  opdracht  van  de  eenheid. 

Status  van  de  actie. 
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Resultaat  van  de  bestrijding  (aantal  doelen  bestreden,  type  doelen 
bestreden,  aantal  doelen  getroffen  etc.). 

De  genoemde  'Action'  entiteiten  zijn  wel  aanwezig  in  het  ISIS-datamodel,  maar 
niet  in  het  ISIS-applicatiemodel. 

•  De  relatie  tussen  een  eenheid  en  de  vakgrens  voor  die  eenheid  wordt  in  ISIS 
niet  expliciet  vastgelegd.  Overwogen  kan  worden  om  hiervoor  de  entiteit 
'object-item-association'  te  gebruiken  en  de  bijbehorende  domeinwaarden  uit 
te  breiden. 

•  Ook  voor  de  relatie  tussen  de  vijand  en  het  zwaartepunt  van  de  luchtaanval 
geldt  dat  hiervoor  'object-item-association'  gebmikt  kan  worden,  met  een 
uitbreiding  van  de  domeinwaarden. 

•  Aangenomen  wordt  dat  een  plan  voor  de  luchtverdediging  in  een  oleaat  wordt 
vastgelegd.  Binnen  ISIS  worden  elementen  van  eenzelfde  plan  ge'fdentificeerd 
op  basis  van  de  'context'.  Om  een  relatie  te  leggen  tussen  een  eenheid  en  het 
luchtverdedigingsplan  van  die  eenheid  kan  gebmik  gemaakt  worden  van  de 
entiteit  'Action-context'.  Anderzijds  kan  het  plan  van  een  eenheid  afgeleid 
worden  uit  de  'owner'  en  'reporting-organisation'. 

•  Bij  de  domeinen  (van  de  te  introduceren  entiteit  AirspaceControlFeature) 
dient  het  element  'Weapon  Control  Status'  te  worden  opgenomen  met  als 
mogelijke  waarden  'Weapons  Free',  'Weapons  Tight',  en  'Weapons  Hold'. 

•  Indien  een  bepaald  niveau  verfijningen  aanbrengt  in  het  AGO  (het  originele 
ACO  blijft  behouden)  dient  (via  object-item-association)  een  relatie  gelegd  te 
worden  tussen  de  originele  ACM  en  de  verfijnde  ACM.  De  applicatie  dient  op 
basis  van  deze  verlljning  te  bepalen  welke  gegevens  aan  de  gebruiker  getoond 
worden. 

•  Behalve  Airspace  Control  Means  bevat  een  ACO  een  aantal  'enkelvoudige' 
gegevens.  Deze  dienen  bij  het  oleaat  gespecificeerd  te  kunnen  worden.  Het 
gaat  hierbij  om  gegevens  zoals: 

De  eenheden  voor  wie  het  ACO  is  bestemd  (dit  zou  wellicht  ook  uit  de 
organisatiestructuur  afgeleid  kunnen  worden). 

Codering  en  referenties. 

-  Rubricering. 

Vijandinformatie  en  informatie  over  eigen  eenheden 

•  Voor  de  lua  bestaat  de  behoefte  om  van  vijandelijke  eenheden  vast  te  leggen 
wat  de  bewapening  van  de  vijandelijke  toestellen  is.  Binnen  ISIS  kan  hiervoor 
de  entiteit  'Holding'  gebruikt  worden.  Het  door  de  vijand  gebruikte  materieel 
dient  dan  als  'Materiel-type'  in  de  database  te  worden  opgenomen. 

•  Voor  het  vastleggen  van  de  door  de  vijand  gebruikte  typen  vliegtuigen  en 
helikopters  en  de  manier  waarop  deze  gebruikt  worden  geldt  dat  ook  dit  met 
behulp  van  de  'Action'  gerelateerde  entiteiten  vastgelegd  kan  worden.  De 
manier  waarop  ze  ingezet  worden  kan  als  tekst  worden  gespecificeerd. 

•  ADINTSUM:  Indien  bij  het  uitvoeren  van  de  actie  de  desbetreffende  gegevens 
in  de  'Action '-entiteiten  worden  vastgelegd,  kan  het  ADINTSUM  hierop 
aansluiten.  In  dat  geval  zijn  het  de  gevolgen  van  de  actie  (zwaartepunt 
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luchtaanvallen,  bestreden  en  uitgeschakelde  vliegtuigtypen  etc.):  in  ISIS- 
termen  'Action-effect'  genoemd.  Voor  zaken  als  'JAMMING'  dienen  specifieke 
entiteiten  /  attributen  toegevoegd  te  worden  of  deze  gegevens  moeten  als  tekst 
bij  de  actie  gespecificeerd  worden. 

Indien  het  beschikbare  personeel  en  materieel  {Holding  en  evt.  Status)  van  de 
vijand  is  vastgelegd  zullen  de  gevolgen  van  een  actie  hierin  hun  weerslag 
vinden:  een  aantal  eenheden  is  bijvoorbeeld  uitgeschakeld. 

•  ADSITREP:  Ook  hier  geldt  dat  de  gegevens  vastgelegd  kunnen  worden  in  een 
combinatie  van  Holding,  Status  en  Action-effect. 

Communiceren  van  ASC-gegevens  en  kvo 

•  In  TICCS  dient  vastgelegd  te  worden  dat  een  eenheid  bepaalde  Means 
verzendt  en  ontvangt.  In  ISIS  wordt  dit  'impliciet'  vastgelegd  doordat  die 
eenheid  de  'eigenaar'  is  van  die  Mean  (perception),  in  combinatie  met  de 
geldende  replicatiecontracten.  Omdat  deze  gegevens  echter  niet  tot  de  ISIS 
database  behoren,  maar  tot  de  meta-database  die  benodigd  is  voor  replicatie, 
wordt  toch  voorgesteld  de  gegevens  in  het  ISIS-datamodel  op  te  nemen  (en 
desnoods  het  replicatiemechanisme  op  basis  hiervan  het  contract  te  laten 
samenstellen).  Het  vastleggen  in  het  ISIS-datamodel  kan  gebeuren  door  middel 
van  de  entiteit  object-item-association,  met  een  uitbreiding  van  de 
domeinwaarden  ('heeft  ontvangen  van  eenheid'  en  'heeft  verstuurd  aan 
eenheid').  Hetzelfde  geldt  voor  de  Means  die  voor  een  bepaalde  eenheid 
relevant  zijn  (domeinwaarde  'heeft  te  maken  met'). 

•  Het  begrip  'kennisgeving  van  ontvangst'  is  geen  onderdeel  van  het  ISIS- 
datamodel.  De  communicatie  van  gegevens  tussen  eenheden  wordt  immers 
door  het  replicatiemechanisme  verzorgd  en  deze  draagt  er  zorg  voor  dat  de 
gegevens  op  de  gespecificeerde  knooppunten  aankomen.  Zoals  kvo  binnen 
TICCS  gebruikt  wordt  is  de  betekenis  meer  dan  alleen  'het  bericht  is 
ontvangen'.  Binnen  ISIS  komt  de  entiteit  'event'  het  beste  in  aanmerking  voor 
het  vastleggen  van  de  'kennisgeving  van  ontvangst'.  Om  hier  daadwerkelijk 
gebruik  van  te  kunnen  maken  dienen  ook  diverse  andere  entiteiten  te  worden 
ingevuld: 

-  object-item-association  (de  twee  organisaties  die  het  betreft) 
action  (omdat  er  een  event  wordt  gebruikt). 

-  perception  (om  de  relatie  tussen  de  association  en  de  event  te  kunnen 
leggen). 

-  action-resource-item  (om  vast  te  leggen  waarvoor  de  kvo  geldt). 

-  action-resource  (omdat  er  een  action-resource-item  nodig  is) . 

Dit  zou  de  zaak  onnodig  complex  maken. 

Voorgesteld  wordt  daarom  een  entiteit  'object-item-receipt'  te  introduceren. 
Hierin  wordt  vastgelegd  van  welke  eenheid  naar  welke  eenheid  het  object-item 
verzonden  wordt  en  ook  of  een  kvo  gegeven  is  (relatie  met  bijvoorbeeld  een 
ACO  of  ACM).  De  nieuwe  entiteit  ziet  er  dan  als  volgt  uit: 


object-item-receipt 

object-item-receipt-send-from-object-item-id 

object-item-receipt-send-to-object-item-id 

object-item-receipt-subject-object-item-id 

object-item-receipt-index 

object-item-receipt-category-code 

object-item-receipt-effective-date 

object-item-receipt-effective-time 

De  entiteit  dient  vervolgens  gerelateerd  te  worden  aan  entiteiten  waarvoor  het 

ontvangstbewijs  relevant  is. 


Default  gegevens  Airspace  Control  Means 

•  In  het  ISIS-datamodel  is  het  niet  (of  door  misbruik  van  bepaalde  entiteiten  / 
attributen)  mogelijk  om  van  een  ACM  default  gegevens  vast  te  leggen  zoals 
deze  in  de  Standing  Operating  Procedures  zijn  verwoord.  Zoals  eerder  vermeld 
wordt  voorgesteld  om  een  entiteit  'Airspace  Control  Feature' te  introduceren. 
Parallel  hieraan  dient  dan  een  entiteit  'Airspace  Control  Feature  Type' 
gei'ntroduceerd  te  worden.  Om  nu  de  default  gegevens  van  een  specifieke 
Airspace  Control  Mean  vast  te  leggen  zou  -  via  object-item-type  -  een  relatie 
tussen  de  entiteit  'Airspace  Control  Mean  Type'  (via  object-type)  en  een 
gecreeerde  'Airspace  Control  Mean'  (via  object-item)  gelegd  moeten  worden. 

In  dat  geval  dient  de  entiteit  'object-item-type'  uitgebreid  te  worden  met  een 
extra  attribuut  die  aangeeft  dat  het  om  een  default-instelling  gaat.  De  applicatie 
kan  hierop  vervolgens  selecteren  en  de  instellingen  gebruiken  (kopieren)  bij 
het  aanmaken  van  een  nieuwe  Mean.  Dit  betekend  wel  dat  deze  functionaliteit 
in  de  applicatie  ingebouwd  moet  worden. 

•  Indien  Airspace  Control  Means  elkaar  overlappen  dient  een  tabel  aanwezig  te 
zijn  waarin  wordt  aangegeven  welke  ACM  prioriteit  heeft. 

Omdat  het  hier  gaat  om  de  relatie  tussen  twee  object-typen  zouden  hiervoor 
binnen  ISIS  de  entiteiten  'establishment'  en  'establishment-detail'  gebruikt 
kunnen  worden.  Omdat  deze  entiteiten  hiervoor  eigenlijk  niet  bestemd  zijn  kan 
ook  overwogen  worden  om  een  nieuwe  entiteit  in  het  leven  te  roepen:  'object- 
type-association'.  De  bestaande  'establishment' entiteiten  kunnen  dan  gezien 
worden  als  een  subtype  van  'object-type-association'. 

Doelinformatie 

•  In  hoofdstuk  8  wordt  ingegaan  op  de  mogelijkheden  om  informatie  van 
luchtdoelen  te  presenteren  op  het  ISIS-GIS.  Omdat  hierbij  de  performance  een 
belangrijk  item  is,  wordt  voorgesteld  de  gegevens  die  afkomstig  zijn  van  de 
TICCS-sensor  niet  in  de  database  vast  te  leggen  (ze  worden  wel  gepresenteerd 
in  het  GIS,  maar  zijn  'vluchtig'). 
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ACM-request 

•  Ervan  uitgaande  dat  de  voorheen  genoemde  'Airspace  Control  Feature' 
aanwezig  is,  kan  een  ACM-request  vastgelegd  worden  door  een  relatie  te 
leggen  tussen  de  Feature  en  de  (aanvragende)  eenheid  (object-item- 
association).  Hiervoor  dient  wel  de  desbetreffende  domeinwaarde  toegevoegd 
te  worden.  Om  ervoor  te  zorgen  dat  de  ACM-request  daadwerkelijk  bij  bet 
hogere  niveau  wordt  ingediend  dient  dit  in  het  contract  met  die  eenheid  te 
worden  opgenomen. 

Air-incident 

•  Een  Air-incident  is  in  ISIS-terminologie  een  'Action'  en  meer  in  het  bijzonder 
een  'Event'.  In  de  'Action-remarks-text'  kan  een  beschrijving  van  het  incident 
worden  opgenomen.  Voor  de  distributie  van  de  Air-incident  naar  de 
belanghebbende  dienen  de  juiste  replicatiecontracten  te  worden  afgesloten. 

Prioriteiten  luchtverdediging 

•  Afhankelijk  van  de  tactische  situatie  wordt  -  van  elk  object  dat  verdedigd  moet 
worden  -  aan  de  hand  van  een  aantal  criteria  (procedures,  tactische  situatie, 
beschikbaarheid  middelen  etc.)  vastgelegd  wat  de  prioriteit  ervan  is.  Indien  de 
'Action'  constructie  wordt  gebruikt  kan  deze  prioriteit  in  de  entiteit  Task' 
worden  vastgelegd. 

Bijlagen  bij  bevel  ( plan  en  voorstel  luchtverdediging) 

•  Plannen  en  bevelen  worden  in  ISIS  ondersteund  door  het  TMS  in  combinatie 
met  kantoorapplicaties  en  templates.  Specifieke  geografisch  gerelateerde 
gegevens  worden  als  oleaten  vastgelegd  waar  vanuit  de  bijlagen  naar  wordt 
verwezen. 

Referentiepunten 

•  Punten  zijn  in  ISIS-terminologie  'Features',  met  als  subtype  'Feature-location' 
van  de  categoric  'Point'.  Om  kenbaar  te  maken  dat  het  om  referentiepunten 
gaat  dient  een  relatie  gelegd  te  worden  met  'Control-Feature-Type'  (via 
feature-type,  object-type  en  object-item-type).  Als  categorie-code  dient  dan  aan 
control-feature-type-cat-code  de  domeinwaarde  'Reference-point'  toegevoegd 
te  worden.  Verder  dient  de  applicatie  zodanig  aangepast  te  worden  dat  bij  elke 
specificatie  van  een  punt  een  relatie  naar  een  referentiepunt  gelegd  kan 
worden.  Referentiepunten  kunnen  in  voorkomende  gevallen  specifiek  voor  een 
operatic  gedefinieerd  worden  (tijdelijk). 


5.4  Samenvatting 

Het  ISIS-datamodel  is  bedoeld  om  de  kern  van  de  C2-processen  op  brigade-  en 
divisieniveau  te  ondersteunen.  Binnen  de  huidige  ISIS-applicaties  wordt  slechts 
een  gedeelte  van  het  totale  ISIS-datamodel  gebruikt  (eenheidsinformatie,  posities. 
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status,  locaties).  Het  applicatie-datamodel  bevat  alleen  dat  gedeelte  dat  voor  de 
huidige  ISIS-applicaties  van  belang  is. 

Om  aan  de  TlCCS-gegevensbehoefte  te  voldoen  dient  ISIS  tenminste  het  'Actie' 
gedeelte  te  ondersteunen  (dit  is  al  onderdeel  van  het  ISIS-uitwisselmodel,  maar 
niet  van  het  ISIS-applicatiemodel).  Daamaast  dient  op  de  volgende  hoofdpunten 
uitbreiding  /  wijziging  van  het  datamodel  plaats  te  vinden: 

•  toevoegen  derde  dimensie  (volumes  etc.)  in  het  applicatie-datamodel; 

•  toevoegen  van  mogelijkheid  om  referentiepunten  te  gebruiken; 

•  toevoegen  entiteit  'AirspaceControlFeature'  (onder  Feature  of 
ControlFeature)  om  Airspace  Control  Means  gerelateerde  gegevens  vast  te 
kunnen  leggen; 

•  uitbreiden  van  'object-item-association'  om  relaties  tussen  gegevens  vast  te 
kunnen  leggen,  zoals  bijvoorbeeld  de  stellinggebieden  van 
eenheden(voomamelijk  uitbreiding  domeinwaarden); 

•  kennisgeving  van  ontvangst; 

•  vastleggen  van  default-waarden  voor  bepaalde  typen  Airspace  Control  Means. 

Voor  bevelen  en  orders  kan  gebruik  gemaakt  worden  van  andere  mogelijkheden, 
zoals  het  Tactical  Message  System  in  combinatie  met  kantoorapplicaties  en 
templates. 
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6.  Communicatie  aspecten  C2-bovenlaag 

6.1  Inleiding 

Deze  paragraaf  gaat  in  op  de  communicatie  binnen  de  C2-bovenlaag  (divisie-  en 
brigadeniveau)  welke  plaatsvindt  ten  behoeve  van  de  lua.  Ingegaan  wordt  op  de  uit 
te  wisselen  gegevens  en  de  beschikbare  communicatie-apparatuur.  Communicatie- 
aspecten  van  de  overige  TICCS-modulen  worden  behandeld  in  [14]. 


6.2  ZODIAC 

ZODIAC^  (Zone  Digitaal  Automatisch  Cryptografisch  beveiligd  netwerk)  is  het 
tactische  communicatienetwerk  van  de  Koninklijke  Landmacht.  Het  ZODIAC 
netwerk  bestaat  uit: 

•  Een  aantal  knooppunten,  elk  bestaande  uit  een  aantal  LOS- 
straalverbindingswagens  (Line  of  Sight)  en  SA-voertuigen  (SchakelAutomaat). 
Deze  worden  rayon  verbindingscentra  genoemd  (RVC). 

•  Een  aantal  gebruikerspunten,  elk  bestaande  uit  ten  minste  een  LOS- 
straalverbindingwagen  en  een  MAP-installatie  (Multiplexer  Access  Point, 
Meervoudig  AansluitPunt).  In  ZODIAC  jargon  worden  deze  punten 
stafverbindingscentra  genoemd. 

De  gebruikers  worden  op  het  netwerk  aangesloten  via  MAP-installaties.  Het 
netwerk  is  transportabel  van  aard  en  de  knooppunten  zijn  apart  verplaatsbaar 
terwijl  de  rest  van  het  netwerk  operationeel  blijft.  Een  knooppunt  kan  operationeel 
worden,  enige  tijd  nadat  het  een  vaste  positie  heeft  ingenomen. 


^  Deze  algemene  beschrijving  van  ZODIAC  is  gedeeltelijk  overgenomen  uit  [9]; 
Definitierapport  ZODIAC  Civiele  Netwerk  Koppelingen,  E.H.  Beekman  et  al., 
TNO  rapport  FEL-91-A343. 
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Knooppunt  (RVC) 


Figuur  9:  Voorbeeld  van  een  ZODIAC  netwerk. 

ZODIAC  is  ontworpen  voor  conventioneel  gebruik  in  een  gebied  (zoals  de 
Noordduitse  Laagvlakte)  maar  met  de  wijziging  in  het  operationele  optreden  van 
de  KL  zal  ook  het  ZODIAC  netwerk  aangepast  moeten  worden.  Dit  wordt  gedaan 
onder  de  noemer  MLUZ  (Mid  Life  Update  ZODIAC).  De  aanpassingen  hebben  als 
doel  ZODIAC  mobieler  te  maken  en  ervoor  te  zorgen  dat  ZODIAC  flexibeler  kan 
worden  ingezet.  Hierbij  moet  gedacht  worden  aan  het  terugbrengen  van  het  aantal 
benodigde  voertuigen  voor  het  opzetten  van  een  netwerk  en  aan  koppelingen  naar 
diverse  andere  netwerken  als  ISDN  en  SATCOM  (Om  ZODIAC  eenheden  over 
lange  afstand  te  kunnen  koppelen). 

De  MLUZ  moet  leiden  tot  een  operationeel  systeem  na  het  jaar  2000. 

6.2.1  Datacommunicatiemogelijkheden 

Binnen  het  huidige  ZODIAC  zijn  diverse  mogelijkheden  beschikbaar  voor 
datacommunicatie. 

1.  Analoge  datacommunicatie 

Data  wordt  via  een  modem  omgezet  in  analoge  signalen  en  aangeboden  aan 
ZODIAC  via  een  DBT  (Digitaal  Beveiligd  Telefoontoestel).  Dit  kan 
bijvoorbeeld  gebruikt  worden  voor  het  aansluiten  van  een  faxapparaat  aan 
ZODIAC.  De  analoge  datacommunicatie  mogelijkheid  wordt  niet  of 
nauwelijks  gebruikt. 

2.  Asynchrone  digitate  datacommunicatie 

Binnen  ZODIAC  is  de  mogelijkheid  om  asynchrone  datacommunicatie  te 
realiseren.  De  beschikbare  bandbreedte  bedraagt  2400  bps  (de  overige 
bandbreedte  wordt  gebruikt  voor  protocoloverhead  en  foutdetectie/correctie 
methoden). 
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5.  Synchrone  digitale  datacommunicatie 

Synchrone  datacommunicatie  kan  uitgevoerd  worden  in  twee  modes.  De 
zogenaamde  class  1  mode  waarbij  een  volledig  kanaal  beschikbaar  wordt 
gesteld  aan  de  gebruiker,  Dit  betekent  een  bandbreedte  van  16  kbps  zonder 
enige  vorm  van  foutcorrectie/detectie. 

De  andere  vorm  is  de  class  4  mode.  Deze  biedt  de  gebruiker  per  kanaal  een 
bandbreedte  van  9600  bps  met  foutcorrectie  (Forward  Error  Correction  (FEC)). 

De  asynchrone  en  de  synchrone  digitale  datacommunicatie  wordt  in  de  MAP- 
installatie  geregeld  met  behulp  van  de  DCC  (DataCommunication  Card).  Deze 
kaart  biedt  ook  de  mogelijkheid  meerdere  kanalen  te  schakelen  om  zodoende  over 
een  grotere  bandbreedte  te  beschikken.  Theoretisch  kunnen  4  kanalen  geschakeld 
worden  wat  in  de  class  1  mode  een  bandbreedte  betekent  van  64kbs  (4xl6kbs).  In 
de  praktijk  is  deze  bandbreedte  echter  niet  haalbaar.  Als  gevolg  van  ZODIAC 
routeringsfouten  is  schakelen  van  meer  dan  2  kanalen  over  een  verbinding 
bestaande  uit  meerdere  trunks  (meer  dan  2  SA’s,  hetgeen  gebruikelijk  is)  niet 
mogelijk.  Bovendien  biedt  deze  class  1  mode  geen  foutcorrectiemogelijkheden. 

Als  gebruik  wordt  gemaakt  van  class  4  communicatie  door  middel  van  een  DBT 
dan  moet  ervoor  gewaakt  worden  dat  geen  interne  ZODIAC 
besturingscommandowoorden  verstuurd  worden  over  de  lijn  in  deze  mode^. 
Aanbevolen  wordt  om  gebruik  te  maken  van  de  klasse  4  mode  voor 
datacommunicatie  wat  een  maximale  bandbreedte  oplevert  van  19.6kbs  (2x9.6 
kbps). 

In  het  kader  van  de  definitiestudie  prototypefase  MLUZ  (zie  [10])  is  voorgesteld  de 
datacommunicatie  mogelijkheden  uit  te  breiden  door  de  DCC  te  vervangen  door 
een  andere  module,  de  ISCU  (Information  System  Connection  Unit).  Deze  module 
kan  maximaal  8  kanalen  stapelen  wat  tot  een  maximale  bandbreedte  van  128kbs 
leidt  (zonder  foutcorrectie). 

6.2,2  ZODIAC  gebruik  binnen  ISIS 

De  koppeling  tussen  ZODIAC  en  ISIS  wordt  gevormd  door  de  binnen  het  ISIS 
project  ontwikkelde  WAN-box.  Deze  verzorgt  de  datacommunicatie  over  ZODIAC. 
In  de  huidige  configuratie  wordt  gebruik  gemaakt  van  synchrone  digitale 
datacommunicatie  in  de  klasse  1  mode  met  een  maximale  bandbreedte  van  32kbs. 
De  WAN-box  wordt  fysiek  geplaatst  in  of  nabij  de  MAP-installatie  (Meervoudig 
Aansluit  Punt)  van  ZODIAC. 

Een  configuratie  zoals  gebruikt  zou  kunnen  worden  in  een  legerkorpsstaf  is 
geschetst  in  Figuur  10.  Binnen  de  commandopost  is  een  netwerk  opgebouwd  rond  4 
LAN-boxen,  die  elk  22  aansluitingen  bieden  (7  glasvezel,  15  UTP/FTP)  naar 
individuele  commandovoertuigen  (In  de  figuur  worden  slechts  enkele  voertuigen 


2 


Ter  illustratie:  het  verzenden  van  een  zogenaamd  cpc  patroon  waarin  aantal  malen 
het  codewoord  RELEASE  heeft  tot  gevolg  dat  de  verbinding  verbroken  wordt. 
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getoond).  In  een  van  de  commandovoertuigen  worden  de  servers  geplaatst.  In  de 
andere  voertuigen  staan  ISIS-clients. 


Figuur  10:  Voorheeld  van  een  commandopostnetwerk. 


6.3  Infrastructuur 


Voorafgaand  aan  het  operationeel  gebruik  van  ISIS  dient  een  communicatieplan  te 
worden  opgesteld.  Hierin  wordt  vastgelegd  welke  knooppunten  met  elkaar  contact 
hebben  en  welke  contracten  afgesloten  worden. 

Indien  wordt  uitgegaan  van  een  divisie  met  totaal  vier  brigades  dan  zullen  de 
volgende  sessies  tussen  de  ISIS-knooppunten  aanwezig  zijn: 


Brigade 


lua  liaison  officier  van  batlerij 
wisselt  van  werkplek  tussen 
batterij  en  brigade 


Batterij 


®  ISIS  knooppunt  (configuratie  van  server  en  clients) 

-  Replicatiesessie 

.  Gegevensuitwisseling  tussen  knooppunten 

(opiossing  nog  onbekertd:  Replicatie?  8MS’  ISIS-Light?) 


Figuur  11:  Configuratie  ISIS  knooppunten  en  sessies  hij  een  divisie  met  vier  brigades. 
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In  bovenstaande  figuur  is  aangegeven  welke  sessies^  zijn  afgesloten  tussen  de  ISIS- 
knooppunten.  Hike  sessie  kan  bestaan  uit  een  aantal  contracten  die  van  het  ene  naar 
het  andere  knooppunt  lopen.  Voor  bi-directionele  gegevensuitwisseling  tussen  twee 
knooppunten  zijn  altijd  twee  sessies  actief  (A->B  en  B->A).  Doordat  gebruik  gemaakt 
wordt  van  routering  is  het  niet  zo  dat  de  getekende  sessie-verbindingen  gelijk  zijn  aan 
de  fysieke  (ZODIAC)  verbindingen  tussen  de  eenheden. 

Als  een  eenheid  onder  bevel  wordt  gesteld  van  een  andere  eenheid,  dan  dienen 
hiervoor  de  gewenste  sessies  te  worden  geopend.  Het  contract  geeft  aan  op  welke 
gebruikersdata  het  knooppunt  zich  abonneert. 

De  contracten  dienen  zodanig  afgesloten  te  worden  dat  alle  benodigde  informatie 
aangeleverd  wordt.  Zolang  nog  geen  filtering  wordt  gebruikt  worden  alle  mutaties 
van  de  gespecificeerde  gebruiker  aangeleverd. 

Contracten  worden  in  principe  voor  een  langere  periode  aangegaan.  Het  tussentijds 
wijzigingen  van  contracten  is  mogelijk  (binnen  ISIS  nog  niet  gebruikt),  maar  het 
gevolg  is  dat  er  een  synchronisatie  plaats  moet  vinden  (tijdsduur  tijdens  oefening: 
ongeveer  4minuten). 

6.4  Gegevensstromen 

Tussen  legerkorps,  divisie  en  brigade  vindt  de  communicatie  plaats  met  behulp  van 
ZODIAC.  Hierover  worden  echter  niet  alleen  de  lua-specifieke  gegevens 
gecommuniceerd,  maar  ook  gegevens  die  voor  andere  commandovoerings- 
activiteiten  van  belang  zijn. 

Omdat  de  totale  gegevensstroom  sterk  afhankelijk  is  van  alle  afgesloten 
(replicatie)contracten  tussen  de  knooppunten  en  het  al  dan  niet  gebruiken  van 
filtering  is  moeilijk  vast  te  stellen  in  hoeverre  de  totaal  beschikbare  bandbreedte 
toereikend  is.  Wei  kan  opgemerkt  worden  dat  tijdens  de  tot  nu  toe  gehouden 
oefeningen  waarbij  ISIS  is  gebruikt  de  beschikbare  bandbreedte  geen  beperkende 
factor  is  geweest. 

Om  toch  enige  inzage  te  krijgen  in  de  TICCS-gegevensstromen  tussen  brigade-  en 
divisieniveau  is  een  overzicht  gemaakt  waarin  de  volgende  gegevens  zijn  verwerkt: 

•  type  gegevensstroom; 

•  zender  en  ontvanger; 

•  verwachte  verzendfrequentie; 

•  berichtomvang; 

•  performance  eisen; 

•  kvo-vereisten. 

Het  overzicht  is  opgenomen  in  bijlage  A. 


^  Een  sessie  wordt  afgesloten  tussen  twee  knooppunten  (nodes),  terwijl  een  contract 
tussen  twee  gebruikers  (owners)  wordt  afgesloten.  Een  knooppunt  bevat  in  de 
praktijk  een  aantal  gebruikers. 
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6.5  Samenvatting 

Met  name  op  het  gebied  van  communicatie  kan  TICCS  niet  los  gezien  worden  van 
de  commandovoeringsactiviteiten  binnen  andere  functionele  deelgebieden  op 
legerkorps-,  divisie-  en  brigadeniveau  die  ook  gebruik  (gaan)  maken  van  de  C2- 
infrastructuur  die  door  ISIS  geboden  wordt.  Daamaast  worden  de  beschikbare 
communicatiefaciliteiten  zowel  voor  data-  als  voice-communicatie  gebruikt. 

Er  is  momenteel  nog  geen  eenduidige  uitspraak  te  doen  of  de  beschikbare 
bandbreedte  toereikend  is.  Tijdens  verschillende  oefeningen  zijn  metingen  aan 
ISIS  uitgevoerd  waarbij  in  kaart  is  gebracht  welke  bandbreedte  benodigd  is  voor 
het  communiceren  van  de  ISIS-gegevens  [15].  Hieruit  blijkt  dat  de  beschikbare 
ZODIAC  bandbreedte  momenteel  nog  geen  beperkende  factor  vormt.  Wellicht 
kunnen  de  resultaten  hiervan  in  combinatie  met  de  te  verwachten  TICCS- 
gegevensstromen  inzicht  geven  in  de  totale  (TICCS  +  ISIS)  gegevensstromen.  Ook 
hier  geldt  dat  de  situatie  zal  veranderen  naarmate  meer  verschillende  functionele 
deelgebieden  (VUIST,  logistiek  etc.)  gebruik  gaan  maken  van  de  ISIS 
infrastructuur. 

Hoewel  het  buiten  de  scope  van  dit  onderzoek  valt  dient  bijzondere  aandacht 
besteed  te  worden  aan  de  communicatie  tussen  de  C2-bovenlaag  en  de  C2- 
onderlaag  (in  het  hoofdstuk  Architectuur  wordt  hier  kort  op  ingegaan).  Punten  van 
aandacht  zijn  hierbij: 

•  Welke  functionaliteit  gaat  geboden  worden  door  het  C2-informatiesysteem  op 
de  lagere  niveaus? 

•  Welke  gegevens  zijn  hiervoor  nodig? 

•  Welke  bandbreedte  is  beschikbaar  voor  de  communicatie  tussen  brigade  en 
batterijniveau? 

•  Op  welke  manier  kunnen  (yerzendlprioriteiten  gesteld  worden  zodat  zeker 
gesteld  is  dat  gegevens  binnen  de  gestelde  tijd  aankomen? 
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7.  Software  aspecten  /  Functionaliteit 


In  hoofdstuk  4  is  per  fiinctionele  zuil  van  TICCS  kort  aangegeven  welke 
functionaliteit  hier  geboden  moet  worden  op  divisie-  en  brigadeniveau.  In  deze 
paragraaf  wordt  de  onderkende  functionaliteit  eerst  beschreven,  waama 
aangegeven  wordt  in  hoeverre  de  gewenste  functionaliteit  met  behulp  van  ISIS  kan 
worden  gerealiseerd.  Aan  het  einde  van  elke  paragraaf  wordt  per  onderkende 
functionaliteit  het  volgende  in  tabelvorm  weergegeven: 

•  prioriteit  (hoog  H  /  middel  M  /  laag  L); 

•  ontwikkelwijze  (al  aanwezig  in  ISIS  /  binnen  ISIS  framework  /  specifiek 
ontwikkelen 

•  (ontwikkel)complexiteit  of  ontwikkelinspanning  (hoog  H  /  middel  M  /  laag  L). 


7.1  Airspace  Control 

Airspace  Control  heeft  binnen  de  lua  de  hoogste  prioriteit.  In  deze  paragraaf  wordt 
nagegaan  in  hoeverre  bepaalde  onderdelen  van  ISIS  (met  name  het  framework) 
voor  het  ontwikkelen  van  de  ASC-functionaliteit  (her)gebruikt  kunnen  worden. 

Achtereenvolgens  worden  de  volgende  aspecten  van  Airspace  Control  behandeld: 

1.  Vastleggen  van  ASC-gegevens 

2.  Opvragen  van  ASC-overzichten 

3.  Distribueren  van  ASC-gegevens 

Bij  minute-to-minute-control  worden  dezelfde  drie  processen  -  zij  het  in  versneld 
tempo  -  doorlopen.  Om  hieraan  te  kunnen  voldoen  worden  specifieke  eisen 
gesteld.  Ook  hierop  wordt  in  de  volgende  paragrafen  ingegaan. 

7.1.1  Vastleggen  ASC-gegevens 

ACO’s  zijn  vastgelegd  in  geformatteerde  berichten  waarin  is  aangegeven  welke 
Airspace  Control  Means  (ACM’s)  in  een  bepaald  gebied  gedurende  een  bepaalde 
periode  actief  zijn.  De  ASC-gegevens  dienen  op  een  geografische  achtergrond 
gemanipuleerd  te  kunnen  worden. 

Airspace  Control  Means  moeten  in  een  grafische  omgeving  op  een  geografische 
achtergrond  (stafkaart)  vastgelegd  en  gewijzigd  kunnen  worden.  Hierbij  is  het  van 
belang  dat  de  juiste  militaire  symbolen  worden  gebruikt  (STD  1477  MI, 
STANAG1241).  Daamaast  dienen  de  Standing  Operating  Procedures  (SOPs)  in 
acht  te  worden  genomen.  In  de  SOPs  is  een  aantal  standaard  regels  voor  ACMs 
vastgelegd  (bijvoorbeeld  de  standaard  hoogte  van  een  Safe  Lane).  Deze  waarden 
dienen  echter  als  default  waarden  door  het  systeem  gebruikt  te  worden;  in 
voorkomende  gevallen  (met  name  bij  intemationale  operaties)  moet  hiervan 
afgeweken  kunnen  worden. 
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Binnen  ISIS  worden  oleaten  gebruikt  voor  het  vastleggen  van  geografische 
gegevens.  Het  ligt  voor  de  hand  elke  AGO  in  een  separaat  oleaat  te  specificeren. 
Voor  de  identificatie  van  het  oleaat  kan  dan  de  datum-tijd  worden  gebruikt. 
Hiemaar  kan  vervolgens  gerefereerd  worden. 

Voor  de  definitie  van  ACM’s  wordt  gebruik  gemaakt  van  referentiepunten.  Deze 
punten  zijn  vooraf  vastgelegd  en  aan  alle  belanghebbenden  (divisie,  brigade  en 
batterij)  gedistribueerd.  Veelal  refereren  ze  aan  markante  objecten  in  het  terrein 
die  ook  vanuit  de  lucht  goed  herkenbaar  zijn.  Ook  in  de  nieuwe  situatie  blijft  de 
noodzaak  van  referentiepunten  daarom  bestaan.  De  referentiepunten  die  door  de 
NAVO  zijn  vastgelegd  bevinden  zich  ongeveer  10  km  uit  elkaar. 

Bij  het  specificeren  van  een  ACM  moet  zoveel  mogelijk  van  de  bestaande 
referentiepunten  gebruik  gemaakt  kunnen  worden.  Binnen  de  huidige 
functionaliteit  van  ISIS  is  het  mogelijk  referentiepunten  vast  te  leggen.  Bij  het 
definieren  van  gebieden  en  lijnen  moet  binnen  ISIS  echter  functionaliteit 
toegevoegd  worden  om  de  objecten  op  basis  van  de  referentiepunten  te  definieren. 
Binnen  het  datamodel  is  deze  mogelijkheid  wel  aanwezig.  Indien  een  ACM 
gedefinieerd  wordt  en  voor  een  van  de  hoekpunten  wordt  in  de  buurt  van  een 
referentiepunt  geselecteerd,  dan  dient  -  zowel  visueel  als  fysiek  -  een  koppeling 
naar  dat  referentiepunt  gelegd  te  worden. 

Voor  elke  ASC  mean  (of  voor  een  aantal  means  gezamenlijk)  moet  het  daamaast 
mogelijk  zijn  de  volgende  gegevens  te  specificeren: 

•  dimensies  (3D)  van  het  desbetreffende  ASC  mean,  gebruik  makend  van 
referentiepunten,  hierbij  dient  zoveel  mogelijk  van  defaults  gebruik  te  worden 
gemaakt  voor  wat  betreft  bijvoorbeeld  breedte  en  hoogte; 

•  datum  en  tijdstip  waarop  het  ASC  mean  effectief  is  (begin  en  einde); 

•  type  kennisgeving  van  ontvangst  dat  gewenst  is  (zie  paragraaf  'Distribueren  van 
ASC-gegevens'); 

•  afhankelijk  van  het  ASC  mean  extra  invulschermen  (voor  de  invoer  van 
bijvoorbeeld  IFF  vereisten,  het  bestemde  doeltype  en  de  vliegrichting). 

Alleen  de  eigenaar  van  een  ACM-object  kan  dat  object  wijzigen.  In  het  algemeen 
kunnen  de  volgende  manipulaties  op  een  ACM-object  uitgevoerd  worden: 
Wijzigingen 

Indien  de  dimensies  of  andere  eigenschappen  van  een  ACM-object  door  de 
eigenaar  gewijzigd  worden  blijven  de  ‘oude’  gegevens  -  conform  het 
ATCCIS  principe  -  opgeslagen  in  de  database.  Nadat  de  gegevens  zijn 
gedistribueerd  dienen  bij  alle  abonnees  de  gewijzigde  gegevens 
weergegeven  te  worden  en  moet  de  gebruiker  hiervan  op  de  hoogte 
gebracht  worden. 

Verwijderen 

Indien  de  eigenaar  van  een  ACM-object  dat  object  verwijdert  blijven  de 
gegevens  in  de  database  opgeslagen  (alleen  de  bij  het  ACM-object 
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vastgelegde  ‘perception’  geeft  aan  dat  de  gegevens  venvijderd  zijn).  Nadat 
de  gegevens  zijn  gedistribueerd  moeten  de  abonnees  hiervan  op  de  hoogte 
gebracht  worden. 

Verfijnen  /aanvullen 

ACO-gegevens  afkomstig  van  het  legerkorps  of  divisie  worden  op  het 
naastlagere  niveau  verfijnd  (omdat  de  originele  ACO  blijft  bestaan  is  het 
beter  te  spreken  van  ‘aangevuld’).  Omdat  het  lagere  niveau  niet  de 
eigenaar  is  van  de  gegevens  blijft  het  originele  ACO-object  in  principe 
bestaan.  Het  gevolg  is  dat  -  indien  de  gebruiker  contracten  heeft  voor 
zowel  de  divisie  als  de  brigade  -  beide  ACO-objecten  afgebeeld  zullen 
worden.  Om  dit  te  kunnen  voorkomen  dient  een  relatie  tussen  het  originele 
object  en  de  verfijning  gelegd  te  worden  (de  database  biedt  hiervoor  de 
benodigde  entiteiten).  De  applicatie  kan  op  basis  hiervan  bepalen  welke 
gegevens  uiteindelijk  afgebeeld  zullen  worden.  De  paragraaf  ‘Distribueren 
ACO-gegevens’  gaat  dieper  in  op  altematieve  oplossingen  voor  deze 
situatie. 

De  inzet  van  RPV’s  kan  zelfstandig  door  het  lagere  niveau  plaatsvinden.  In  dit 
geval  definieert  het  desbetreffende  niveau  de  mean  buiten  de  ACO  om.  Indien  er 
consequenties  zijn  voor  geldende  ACO’s  wordt  het  hogere  niveau  hiervan  op  de 
hoogte  gebracht. 

Door  het  hele  TICCS-systeem  wordt  gebruik  gemaakt  van  tijden.  Voor  de 
betrouwbaarheid  van  de  gegevens  is  het  van  groot  belang  dat  alle  ‘klokken’  in  het 
systeem  gesynchroniseerd  zijn.  Onder  brigadeniveau  gebeurt  dit  synchroniseren 
door  GPS  of  radio.  Voor  divisie-  en  brigadeniveau  dienen  soortgelijke  procedures 
vastgelegd  te  worden. 

In  het  geval  van  minute-to-minute-control  dienen  de  gegevens  snel  en  onder 
tijdsdruk  ingevoerd  en  verspreid  te  kunnen  worden.  Hiervoor  is  een  aantal 
aanpassingen  gewenst: 

•  de  user-interface  moet  zodanig  zijn  dat  veel  voorkomende  handelingen 
intuitief  en  met  zo  min  mogelijk  handelingen  uitgevoerd  kunnen  worden; 

•  gegevens  moeten  onder  alle  omstandigheden  direct  verzonden  worden; 

•  ontvangstbevestigingen  dienen  direct  teruggestuurd  te  worden; 

•  de  gegevens  dienen  direct  op  het  ISIS-GIS  afgebeeld  te  worden. 

Indien  ISIS  wordt  toegepast  kan  het  vastleggen  van  ASC  gegevens  met  behulp  van 
ISIS  als  volgt  plaatsvinden: 

1.  Creeer  een  oleaat  en  geef  aan  voor  welke  periode  deze  geldig  is  (de  ACO- 
identificatie). 

2.  Leg  de  Airspace  Control  Means  met  behulp  van  de  muis  vast  en  maak  daarbij 
gebruik  van  referentiepunten.  Voeg  indien  nodig  additionele  referentiepunten 
toe. 


3.  Voer  extra  gegevens  in  die  specifiek  zijn  voor  de  desbetreffende  Airspace 
Control  Mean  (bijv.  hoogte  en  IFF  vereisten). 

4.  Sla  de  objecten  op  in  de  ISIS  database.  Afhankelijk  van  de  geldende 
replicatiecontracten  worden  de  gegevens  nu  gedistribueerd  naar  de 
belanghebbenden. 

De  paragraaf  ‘Distribueren  ASC-gegevens’  gaat  in  op  altematieve  manieren  om 
ASC-gegevens  ook  op  de  conventionele  (tekstuele)  manier  te  behandelen. 

7.1.2  Opvragen  ASC-overzichten 

De  divisie  en  brigade  dienen  op  elk  ogenblik  inzicht  te  hebben  in  de  momenteel 
van  kracht  zijnde  en  de  uitstaande  ACO’s,  en  de  bevestigde  /  onbevestigde  ACO’s. 
Om  dit  mogelijk  te  maken  moeten  de  volgende  overzichten  gegenereerd  kunnen 
worden: 

De  momenteel  van  kracht  zijnde  Airspace  Control  Means. 

Binnen  ISIS  zijn  oleaten  een  manier  om  dit  zichtbaar  te  maken.  In  dit  geval  dient 
er  een  ‘Current  ACO’  oleaat  ontwikkeld  te  worden.  Alle  uitgegeven  ACO’s  dienen 
van  een  bepaald  kenmerk  voorzien  te  worden  (om  ze  te  onderscheiden  van  ACM- 
requests).  Het  ‘Current  ACO’  oleaat  dient  te  selecteren  op  dit  kenmerk  en 
uitgaande  van  de  uitgegeven  Airspace  Control  Means  alle  momenteel  van  kracht 
zijnde  ACM -objecten  uit  te  filteren  en  deze  afte  beelden  op  het  oleaat  (dus 
ongeacht  de  eigenaar  en  het  oleaat  waarvan  de  ACM-obJecten  afkomstig  zijn). 
Evenzo  dienen  ACM-objecten  die  niet  meer  geldig  zijn  van  het  oleaat  verwijderd 
te  worden  (het  oleaat  loop  dus  automatisch  'mee  met  de  tijd',  bovendien  kan  van 
elke  ACM-object  opgevraagd  worden  in  welke  periode  deze  geldig  is).  Paragraaf 
‘Distribueren  van  ASC-gegevens’  gaat  in  op  het  probleem  van  eigenaarschap  en 
mogelijke  oplossingen  hiervoor.  De  replicatiecontracten  zullen  zodanig  opgezet 
moeten  worden  dat  alle  eenheden  de  beschikking  hebben  over  de  momenteel  van 
kracht  zijnde  ACM’s. 
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Legerkorps  AGO  Divisi©  AGO  Loss©  AGM's  voor  bijv.  minute-to-minute-control 


Figuur  12:  Samenstelling  van  'Current-ACO'-oleaat  uit  ACO's  en  losse  ACMs. 

Behalve  de  grafische  presentatie  van  de  van  kracht  zijnde  ACO-gegevens  op  een 
geografische  achtergrond  dient  de  gebruiker  ook  een  tekstueel  overzicht  hiervan  op 
te  kunnen  vragen  en  dit  af  te  kunnen  drukken. 

De  uitstaande  (komende)  Airspace  Control  Means, 

Hiervoor  geldt  in  grote  lijnen  hetzelfde  als  de  van  kracht  zijnde  ACM’s.  In 
tegenstelling  tot  de  huidige  ACO  periode  moet  de  gebruiker  hier  inzicht  krijgen  in 
de  Means  voor  de  komende  ACO  periode.  Binnen  ISIS  worden  hiervoor  oleaten 
gebruikt.  Voor  de  uitstaande  ACM’s  dient  ook  een  speciaal  oleaat  ontwikkeld  te 
worden;  het  zogenoemde  ‘Next  ACO’  oleaat.  Door  op  dit  oleaat  een  bepaalde  ACM 
te  selecteren  kan  de  gebruiker  opvragen  op  welk  tijdstip  het  geselecteerde  ACM 
van  kracht  wordt.  Dit  dient  ook  tekstueel  weergegeven  te  kunnen  worden.  Het 
‘Next  ACO’  oleaat  dient  ook  voortdurend  ververst  te  worden.  Indien  een  ACM  van 
kracht  is  geworden  dient  het  ACM  van  het  ‘Next  ACO’  oleaat  verwijderd  te 
worden  en  op  het  ‘Current  ACO’  oleaat  te  verschijnen. 

De  bevestigde  en  nog  niet  bevestigde  ACO's. 

Een  ACO  specificeert  het  gebruik  van  een  aantal  ACM’s.  Voorheen  is  vermeld  dat 
elke  ACO  in  een  separaat  oleaat  wordt  vastgelegd.  Per  gepland  ACO  wordt  een 
bevestiging  uitgevoerd,  terwijl  bij  niet  (of  op  zeer  korte  termijn)  geplande  acties 
voor  elke  ACM  een  bevestiging  dient  te  worden  gegeven.  De  volgende  paragraaf 
‘Distribueren  ASC-gegevens’  gaat  in  op  de  mogelijkheden  om  deze  bevestiging  uit 
te  voeren. 

In  elk  geval  dient  de  eenheid  die  de  ACO  heeft  aangemaakt  kolomsgewijs  per 
ontvangende  eenheid  een  overzicht  te  krijgen  van  de  kvo-status  (mogelijk  een 
aanpassing  in  het  datamodel  om  dit  vast  te  kunnen  leggen  en  in  de 
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replicatiecontracten  om  de  kvo-gegevens  naar  de  zendende  eenheid  terug  te 
versturen.  Een  andere  mogelijkheid  is  om  de  bevestiging  ‘los’  van  de 
replicatiecontracten  te  versturen). 

In  het  bijzonder  voor  minute-to-minute-control  geldt  dat  de  overzichten  snel 
opgevraagd  moeten  kunnen  worden  en  snel  inzicht  moeten  geven  in  de  huidige 
situatie. 

Om  de  gegevens  in  voorkomende  gevallen  voorrang  te  verlenen  boven  andere 
berichten  is  het  nodig  dat  hieraan  een  (verzend)prioriteit  wordt  toegekend.  In  ISIS 
is  dit  momenteel  niet  mogelijk.  In  het  hoofdstuk  architectuur  wordt  hier  dieper  op 
ingegaan. 

7.1.3  Distribueren  ASC-gegevens 

Bij  gebruik  van  geautomatiseerde  ondersteuning  dient  de  gebruiker  op  elk  ogenblik 
inzicht  te  hebben  in  de  bereikbaarheid  van  andere  eenheden.  Het  systeem  dient  dit 
periodiek  te  controleren  en  bij  uitgevallen  verbindingen  een  waarschuwing  te 
genereren.  Momenteel  wordt  binnen  ISIS  functionaliteit  ontwikkeld  die  in  het  geval 
van  een  uitgevallen  verbinding  de  beheerder  van  het  systeem  waarschuwt  zodat 
deze  verdere  actie  kan  ondernemen. 

Voor  de  distributie  van  de  ACO’s  geldt  het  volgende: 

•  het  legerkorps  verzendt  AGO’ s  naar  de  divisie; 

•  de  divisie  verzendt  ACO’s  naar  de  brigades,  de  afdeling  lua  en  de  brigade 
batterij; 

•  de  brigade  verzendt  ACO's  naar  de  batterij. 

Onder  batterijniveau  wordt  de  AGO  omgezet  in  een  Weapon  Gontrol  Order  (WGO). 
Deze  wordt  gebruikt  bij  de  aansturing  van  de  wapensystemen. 
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XXX  AGO 


WCO 


Figuur  13:  ACO  gegevensstromen  tussen  hogere  niveaus. 

Bij  het  verspreiden  van  ACO’s  is  het  mogelijk  dat  een  bepaald  niveau  kleine 
aanvullingen  (voor  zover  dit  niet  in  strijd  is  met  het  originele  ACO)  aanbrengt  in 
de  ACO  van  het  hogere  niveau  alvorens  de  ACO  naar  het  lagere  niveau  te 
versturen.  Het  gaat  hierbij  veelal  om  verfijningen  en  het  inperken  van  het  gebied 
van  belangsteiling.  Binnen  ISIS  is  dit  in  strijd  met  het  eigenaarsprincipe;  alleen  de 
eigenaar  is  immers  gerechtigd  om  de  door  hem  gecreeerde  gegevens  te  wijzigen. 
Het  gaat  in  de  praktijk  om  losse  ACM’s  die  worden  verspreid  ten  behoeve  van 
bijvoorbeeld  Heli-inzet  en  Close  Air  Support  (CAS). 

Er  zijn  in  deze  situatie  drie  mogelijke  oplossingen.  Om  een  en  ander  te 
verduidelijken  wordt  er  in  het  onderstaande  van  uitgegaan  dat  het  legerkorps  een 
ACO-oleaat  aanmaakt  en  dat  de  divisie  hierin  wijzigingen  aanbrengt  alvorens  de 
gegevens  naar  de  brigade  te  versturen; 
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Figuur  14:  Verfijningen  aanbrengen  in  Airspace  Control  Orders. 

1.  De  divisie  kopieert  de  gegevens  van  het  legerkorps-oleaat  naar  een  eigen  oleaat, 
brengt  de  wijzigingen  /  verfijning  aan  en  bewaart  de  gegevens.  De  divisie  is  nu 
eigenaar  van  de  (originele  en  gewijzigde)  gegevens  op  dit  oleaat.  Door  het 
afgesloten  replicatiecontract  worden  de  gegevens  naar  de  brigade  verstuurd.  Dit 
heeft  als  nadeel  dat  er  onnodig  veel  gedupliceerde  gegevens  in  de  database 
worden  vastgelegd.  Het  voordeel  is  dat  de  brigade  nu  geen  replicatiecontract 
met  het  legerkorps  hoeft  af  te  sluiten. 

2.  De  brigade  heeft  een  contract  met  zowel  het  legerkorps  als  de  divisie.  Het 
complete  (originele)  oleaat  wordt  ook  door  de  divisie  rechtstreeks  van  het 
legerkorps  ontvangen.  Nadat  de  divisie  de  wijzigingen  heeft  aangebracht 
(eigenlijk  objecten  heeft  toegevoegd  /  verfijnd)  worden  die  gegevens  met 
behulp  van  het  replicatiemechanisme  naar  de  brigade  verstuurd.  De  brigade 
‘ziet’  nu  zowel  de  originele  objecten  van  het  legerkorps  als  de  door  de  divisie 
toegevoegde  objecten.  Dit  kan  voorkomen  worden  door  de  divisie  bij  het 
toevoegen  van  objecten  een  relatie  te  laten  leggen  tussen  de  originele  gegevens 
en  de  gewijzigde  /  verfijnde  gegevens  (in  ATCCIS  termen  een  ‘object-item- 
association’).  In  de  applicatie  moet  dan  functionaliteit  ingebouwd  worden  die 
aan  de  hand  hiervan  kan  bepalen  welke  gegevens  getoond  worden.  Nadeel  is 
dat  er  onnodig  veel  contracten  afgesloten  dienen  te  worden  hetgeen  ten  koste 
gaat  van  de  beheersbaarheid  en  dat  er  functionaliteit  aan  de  applicatie 
toegevoegd  moet  worden.  Daamaast  is  de  kans  aanwezig  dat  de  brigade 
irrelevante  gegevens  aangeleverd  krijgt  en  dat  het  beeld  'leeft'  zolang  de  divisie 
wijzigingen  aanbrengt. 
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3.  Het  replicatiemechanisme  biedt  de  mogelijkheid  van  ‘contract-forwarding’. 
Contract-forwarding  betekent  in  dit  voorbeeld  dat  de  brigade  bij  de  divisie  een 
contract  afsluit  waarbij  deze  zich  -  behalve  op  de  gegevens  van  de  divisie  - 
abonneert  op  de  gegevens  van  het  legerkorps.  Het  replicatiemechanisme 
bewaakt  hierbij  de  referentiele  integriteit  van  de  gegevens  die  naar  de  brigade 
worden  verstuurd. 

Indien  contract-forwarding  geimplementeerd  wordt  zal  de  brigade  zowel  de 
originele  gegevens  van  het  legerkorps  als  de  toegevoegde  gegevens  van  de 
divisie  ontvangen.  Voordeel  is  dat  de  brigade  alleen  contracten  afsluit  met  de 
divisie,  niet  met  het  legerkorps.  De  nadelen  zijn  gelijk  aan  die  van  het  tweede 
altematief.  Contract  forwarding  is  momenteel  nog  niet  binnen  ISIS 
geimplementeerd. 

Het  eerste  altematief  heeft  als  voordeel  de  grote  mate  van  flexibiliteit  in  een 
operationele  omgeving.  Onafhankelijk  van  de  bron  van  de  informatie  (bijv. 
informatie  afkomstig  van  buitenlandse  eenheden,  in  welke  vorm  dan  ook)  kan  te 
alien  tijde  een  ACO  voor  de  eigen  eenheden  samengesteld  worden.  Ook  kan  snel 
en  dynamisch  ingespeeld  worden  op  de  situatie,  met  name  het  gebied  van 
belangstelling  kan  eenvoudig  aangepast  worden.  Wellicht  kan  in  eerste  instantie 
gekozen  worden  voor  dit  altematief  en  later  nagegaan  worden  of  de  voordelen  van 
altematief  twee  en  drie  (de  brigade  is  al  in  een  zo  vroeg  mogelijk  stadium  op  de 
hoogte  van  het  initiele  ACO  en  er  worden  minder  gedupliceerde  gegevens 
vastgelegd)  daadwerkelijk  tot  hun  recht  komen. 

Als  de  ACO-gegevens  zijn  ontvangen  dient  dit  bevestigd  te  worden  door  middel 
van  een  kennisgeving  van  ontvangst  (kvo).  Er  zijn  twee  vormen  van  kennisgeving 
van  ontvangst  te  onderscheiden: 
standaard  kvo: 

Om  aan  te  geven  dat  het  bericht  ‘in  goede  orde  is  ontvangen’;  zonder  daarmee 
aan  te  geven  dat  het  bericht  aan  alle  belanghebbenden  is  medegedeeld.  Dit  type 
kvo  kan  direct  na  de  ontvangst  van  het  bericht  worden  doorgegeven. 
wapensysteem  kvo: 

Om  aan  te  geven  dat  het  bericht  in  goede  orde  is  ontvangen,  is  doorgegeven  tot 
op  het  laagste  niveau  (wapensysteemniveau)  en  dat  van  het 
wapensysteemniveau  een  temgmelding  is  gekomen  dat  het  bericht  is  ontvangen, 
begrepen  en  dat  de  bemanning  uitvoering  zal  geven  aan  het  bericht.  Dit  type 
bericht  zal  dus  eerst  tot  op  wapensysteemniveau  moeten  worden  doorgegeven; 
pas  dan  kan  elk  niveau  -  als  alle  onderliggende  eenheden  een  kvo  hebben 
gegeven  -  een  kvo  naar  het  hogere  niveau  doorgeven. 
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Figuur  15:  Twee  typen  van  kennisgeving  van  ontvangst  (kvo). 

Het  standaard  kvo  wordt  gebruikt  voor  alle  vooraf  geplande  ACO’s.  Het 
wapensysteem  kvo  wordt  vooral  gebruikt  bij  minute-to-minute-control  en  indien  op 
korte  termijn  acties  uitgevoerd  moeten  worden.  Voor  de  veiligheid  is  het  daarbij 
van  belang  dat  zeker  is  dat  de  opdracht  tot  op  het  laagste  niveau  is  doorgedrongen 
voordat  de  actie  kan  worden  uitgevoerd.  In  dergelijke  gevallen  wordt  per  Airspace 
Control  Mean  een  kvo  gevraagd. 

Gelet  op  de  semantiek  van  het  begrip  ‘kennisgeving  van  ontvangst’  houdt  dit 
begrip  meer  in  dan  ‘het  bericht  is  ontvangen’.  Het  impliceert  ook  dat  de  ontvanger 
kennis  genomen  heeft  van  het  bericht  en  hieraan  uitvoering  zal  geven.  Het  is 
daarom  niet  wenselijk  deze  functionaliteit  volledig  te  automatiseren.  Wei  kan  de 
gebruiker  ondersteund  worden  in  het  op  een  zo  eenvoudig  mogelijke  wijze 
uitvoeren  van  de  ‘kennisgeving  van  ontvangst’;  bijvoorbeeld  door  de  bevestiging 
door  middel  van  selectie  van  een  button  te  activeren.  Een  andere  mogelijkheid  is 
de  objecten  waarvan  een  kvo  verstuurd  moet  worden  te  selecteren  en  vervolgens 
de  kvo  te  activeren  (in  de  database  is  immers  vastgelegd  wie  de  eigenaar  is  van  de 
objecten  en  dus  aan  wie  de  kvo  verstuurd  moet  worden).  De  fysieke  implementatie 
kan  op  verschillende  manieren  uitgevoerd  worden.  De  kvo  kan  in  de  database 
vastgelegd  worden  en  met  behulp  van  replicatie  verspreid  worden  of  de  kvo  kan 
rechtstreeks  over  het  net  verstuurd  worden. 

Een  van  de  eisen  van  TICCS  is  dat  het  systeem  als  geheel  robuust  moet  zijn. 
Indien  een  systeem  uitvalt  moet  op  de  oude  manier  verder  gewerkt  kunnen  worden 
Een  oplossing  hiervoor  is  om  de  ACO’s  zoals  die  momenteel  gebruikt  worden  (in 
tekstuele  vorm)  ook  in  de  nieuwe  situatie  te  blijven  ondersteunen.  Op  elk  niveau 
moet  het  daarom  mogelijk  zijn  de  ACO  in  tekstformaat  door  het  systeem  te  laten 
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genereren  vanuit  het  ISIS-GIS  en  om  ACO’s  die  in  tekstformaat  zijn  opgesteld 
door  het  systeem  in  te  laten  lezen  en  om  te  laten  zetten  in  het  ISIS-GIS.  De  AGO 
kan  dan  verspreid  worden  (via  datacommunicatie  of  een  altematief  medium)  en  op 
een  lager  niveau  in  het  systeem  ingevoerd  worden 

Door  het  AGO  ook  op  de  conventionele  manier  te  ondersteunen  kunnen  de 
gegevens  in  geval  van  nood  ook  met  niet  Nederlandse  eenheden  -  die  zich  houden 
aan  de  AGO-standaard  -  uitgewisseld  worden.  De  applicatie  die  het  AGO 
berichtenformaat  inleest  /  wegschrijft  zal  veel  overeenkomst  vertonen  met  de 
binnen  ISIS  al  ontwikkelde  HEROS  gateway. 

De  lua-officier  van  de  batterij  treedt  op  als  liaison-officier  tussen  de  batterij  en  de 
brigade.  Fysiek  is  deze  officier  (met  werkstation)  het  merendeel  van  de  tijd  op  de 
brigade  aanwezig.  Het  is  van  belang  dat  deze  lua-officier  zowel  op  de  brigade  als 
op  de  batterij  beschikt  over  dezelfde  functionaliteit.  Op  de  batterij  is  geen 
ZODIAG  aansluiting.  Er  zijn  eigenlijk  twee  knelpunten: 

1.  De  liaison-officier  heeft  geen  vaste  werkplek.  Gezien  de  middelen  die  de 
officier  tot  zijn  beschikking  heeft  en  zijn  ‘actieradius’  kan  hier  het  beste 
gebruik  gemaakt  worden  van  een  FM9000  verbinding,  waardoor  de  liason- 
officier  altijd  contact  heeft  met  bevelvoerende  eenheid  (brigade). 

2.  De  liaison-officier  heeft  -  vergeleken  met  de  middelen  op  divisie-  en 
brigadeniveau  -  slechts  een  beperkte  bandbreedte  tot  zijn  beschikking.  Hiermee 
zal  rekening  gehouden  moeten  worden  bij  het  vastleggen  van  de 
replicatiecontracten. 

In  het  hoofdstuk  'Architectuur'  wordt  hier  dieper  op  ingegaan. 

ACM-request 

AGM-requests  worden  ingediend  door  het  legerkorps,  Gommandant  Achtergebied, 
Divisie  en  Brigade  bij  het  naasthogere  niveau.  Het  Divisie-  en  Brigade  AGM- 
request  wordt  verzonden  naar  het  naasthogere  niveau  en  tevens  naar  de 
ondercommandanten.  Het  legerkorps  AGM-request  wordt  verzonden  naar  een 
hoger  niveau  en  tevens  als  informatie  naar  nevenlegerkorpsen,  divisies, 
Gommandant  Achtergebied  (GOA)  en  tactische  helikoptergroep  (THG). 
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Figuur  16:  ACM-request  gegevensstromen  tussen  de  hogere  niveaus. 

De  ACM-requests  kunnen  op  dezelfde  manier  ingevoerd  worden  als  de  ACO’s: 
namelijk  door  het  vastleggen  van  de  Means  in  oleaten  van  het  ISIS-GIS.  Ook  de 
presentatie-  en  verwerkingswijze  dient  conform  de  ACO’s  te  zijn.  De 
replicatiecontracten  dienen  echter  zodanig  te  zijn  dat  de  ACM-requests  de 
hierboven  aangegeven  ‘routes’  kunnen  afleggen.  Omdat  in  een  aantal  gevallen  de 
contracten  tussen  eenheden  alleen  ACM-requests  betreffen  is  het  -  in  verband  met 
databasevervuiling  en  snelheid  van  communicatie  /  beschikbare  bandbreedte  -  van 
belang  dat  replicatie  in  staat  is  hierop  x&filteren. 

Een  andere  mogelijkheid  is  de  ACM-requests  via  het  Tactical  Message  System  te 
versturen.  Bij  het  opstellen  van  de  request  kan  dan  de  tekstuele  uitvoer  van  het  CIS 
gebruikt  worden  om  aan  te  geven  welke  ACM’s  worden  aangevraagd.  In  dit  geval 
dienen  hiervoor  templates  ontwikkeld  te  worden  en  moet  de  gebruiker  het  initiatief 
nemen  om  de  gegevens  te  presenteren.  De  gegevens  hebben  in  dit  geval  geen 
relatie  met  andere  databasegegevens  en  kunnen  niet  met  behulp  van  contracten 
worden  gedistribueerd. 

In  de  volgende  tabel  is  een  samenvatting  weergegeven  van  de  benodigde 
functionaliteit  -  voor  zover  deze  betrekking  heeft  op  ASC  -  en  de  manier  waarop 
deze  ontwikkeld  kan  worden. 
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Tabel  1:  ASC  functionaliteit  in  relatie  tot  ISIS. 


Functionaliteit 

Prio 

Ontwikkelwijze 

Compl 

Opmerkinfi 

Vastleggen  ACM  op 
geografische  achtergrond 

H 

met  framework 

M 

•  ACM  requests  dienen  op  een 
gelijksoortige  manier  als  ACO’s  te 
worden  behandeld  (ook  overlays, 
zelfde  tekenwijze  etc.). 

•  Toevoegen  derde  dimensie  bij  alle 
ACM’s,  zowel  invoermogelijkheid  als 
vastlegging  in  database. 

•  Militaire  symbolen  specifiek  voor  lua 
afbeelden  volgens  STD  1477  MI  / 
STANAG1241. 

•  Toegankelijk  maken  specifieke  ACM 
attributen. 

•  Opnemen  extra  attributen  in  applicatie- 
en  uitwisselingsdatabase. 

•  Alleen  bevoegde  functionarissen 
moeten  verfijningen  in  ACO’s  kunnen 
aanbrengen. 

•  Het  moet  mogelijk  zijn  om  lijnen  / 
gebieden  etc.  te  defmieren  door 
gebruik  te  maken  van  referentiepunten. 

De  relatie  tussen  de  lijnen  /  gebieden 
en  de  referentiepunten  moet  blijven 
bestaan.  Ook  losse  UTM-coordinaten 
moeten  gebruikt  kunnen  worden. 

•  Gebruiken  van  Standing  Operating 
Procedures  (SOPs)  als  defaultwaarden 
voor  attributen.  Deze  moeten  te 
ovemilen  zijn. 

•  Standaard  namen  voor  oleaten  waarop 
ACO’s  gespecificeerd  worden. 

•  Indien  een  bepaald  organiek  niveau  het 
ACO  van  een  hoger  niveau  verfijnt  en 
niet  wil  dat  het  lagere  niveau  de 
originele  gegevens  ‘ziet’,  dan  dient  er 
bij  het  verfijnen  een  relatie  tussen  de 
twee  gelegd  te  worden.  Hiervoor  dient 
extra  functionaliteit  toegevoegd  te 
worden  aan  de  applicatie  die  het 
‘Current  ACO’  oleaat  laat  zien. 

Referentiepunten 

H 

Met  framework 

L 

•  Alle  in  gebruik  zijnde  referentiepunten 
opnemen  in  database. 

•  Voor  elk  niveau  mogelijkheid  bieden 
nieuwe  referentiepunten  te  defmieren. 

•  Distributie  van  referentiepunten  naar 
alle  van  belang  zijnde  niveaus. 

•  Filtering  bij  replicatie  gewenst. 

•  De  NAVO  referentiepunten  mogen  niet 
zondermeer  gewijzigd  kunnen  worden. 
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Tijdsynchronisatie 

H 

Specifiek 

ontwikkelen 

M..H 

•  Alle  ISIS  systemen  dienen 
‘lijdsynchroon’  le  lopen. 

•  Op  divisie  en  brigadeniveau 
synchronisatie  uitvoeren  m.b.v.  GPS  of 
radio. 

Van  kracht  zijnde  ACM’s 

H 

Framework 

M..H 

•  Ontwikkelen  ‘Current  ACO’  oleaat  dat 
-  ongeacht  eigenaar  of  oleaat  waarvan 
het  ACM  afkomstig  is  -  alle  momenteel 
van  kracht  zijnde  ACM-objecten 
uitfiltert  en  deze  afbeeld.  De 
tijdstippen  begin-  en  einde  geldigheid 
zijn  hierbij  het  uitgangspunt. 

•  Het  'Current  ACO'  oleaat  dient  met  de 
tijd  'mee  te  lopen*. 

•  Indien  Means  op  het  scherm 
gepresenteerd  of  juist  verwijderd 
worden  dient  dit  zowel  visueel  als 
auditief  kenbaar  te  worden  gemaakt. 

•  Na  selectie  van  een  ACM  dient  de 
gebruiker  een  overzicht  te  krijgen  van 
de  eigenschappen  van  de  ACM  (tot 
wanneer  is  het  actief.  van  wie  is  het 
afkomstig  en  wat  zijn  verdere 
bijzonderheden  van  het  ACM). 

Tekstuele  overzichten 

H 

Framework 

L 

•  Elk  organiek  niveau  dient  een  tekstueel 
overzicht  op  te  kunnen  vragen  van  de 
van  kracht  zijnde  ACO’s  en  van  de  nog 
komende  ACO’s. 

•  De  overzichten  dienen  ook  afgedrukt  te 
kunnen  worden. 

Komende  ACM’s 

! 

H 

Framework 

M 

•  Ontwikkelen  ‘Next  ACO’  oleaat  dat  - 
ongeacht  eigenaar  of  oleaat  waarvan  de 
ACM  gegevens  afkomstig  zijn  -  alle 
nog  niet  van  kracht  zijnde  ACM- 
objecten  uitfiltert  en  deze  afbeeld.  Het 
oleaat  dient  voortdurende  up-to-date 
gehouden  te  worden. 

•  Bij  selectie  van  een  specifiek  ACM  op 
het  oleaat  dient  de  gebruiker 
duidelijkheid  te  hebben  wanneer  de 

ACM  van  kracht  wordt  en  welke 
bijzonderheden  er  voor  het  ACM  zijn 
vastgelegd. 

•  Definieren  replicatiecontracten  voor 
alle  belanghebbenden. 

Bevestiging  van 
ontvangst 

H 

Framework 

M 

•  Overzicht  op  kunnen  vragen  van  de 
bevestigde  en  nog  niet  bevestigde 

ACO’s  (grafische,  tekstueel  en  op 
papier). 

•  Kvo  dient  zowel  per  ACO  als  per 

ACM  gegeven  te  kunnen  worden 
(afhankelijk  van  wat  de  opsteller  van 
het  ACO/ACM  wil  en  het  feit  of  het 
een  ‘planned’  action  is). 
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•  Eventueel  kan  functionaliteit 

ontwikkeld  worden  om  de  kvo 

distributie  te  automatiseren  en  het 
geven  van  een  kvo  te  vergemakkelijken 
(niet  het  geven  van  de  kvo 
automatiseren). 

•  Kvo  melding  eventueel  opnemen  in  de 
database  (aanpassing). 

Sign  of  life 

H 

Framework 

L 

•  De  gebruiker  moet  snei  inzicht  hebben 
in  de  activiteit  van  andere  ‘nodes*. 

Indien  een  node  die  informatie 
aanlevert  tijdelijk  buiten  gebniik  is 
moet  dit  zo  snel  mogelijk  aan  de 
beheerder  gemeld  worden,  De 
beheerder  kan  hierop  verdere  actie 
ondememen  (Momenteel  wordt  deze 
functionaliteit  binnen  ISIS 
ontwikkeld).  Het  is  gcwenst  dat  de 
gebruikers  van  het  inactief  zijn  van  een 
node  zo  snel  mogelijk  automatisch  op 
de  hoogte  worden  gebracht. 

Distribute  ASC  gegevens 

H 

Framework 

M..H 

•  Specificeren  van  replicatiecontracten. 

♦  Mogelijke  oplossing:  implementeer 
Contract  Forwarding  in  Replicatie. 

Conventionele  werkwijze 

H 

Framework  / 
Hergebruik 

HERDS 

functionaliteit 

H 

•  Het  systeem  dient  de  mogelijkheid  te 
bezitten  een  grafisch  ingevoerd  AGO  te 
‘vertalen*  naar  het  conventionele 
ACO-formaat  (robuustheid). 

•  Conventioneel  opgestelde  ACO’s 
dienen  door  het  systeem  ingelezen  te 
kunnen  worden  en  in  grafische  vorm 
gepresenteerd  te  kunnen  worden, 

•  Oplossen  eigenaar  probleem. 

ACM-requests 

H 

TMS 

Framework 

L 

Voor  ACM-requests  zijn  er  twee 
mogelijkheden: 

1 .  Het  vastleggen  in  een  oleaat  van  het 
ISIS-GIS.  In  dit  geval  dienen 
replicatiecontracten  opgesteld  te 
worden  en  is  filtering  gewenst. 

Voordeel  is  dat  de  gegevens  direct 
voor  planningsdoeleinden  gebruikt 
kunnen  worden. 

2,  Het  opstellen  van  het  request  met 
behulp  van  het  TMS.  Hiervoor  kan 
bijvoorbeeld  de  tekstuele  uitvoer  die 
door  het  ISIS-GIS  gegenereerd  kan 
worden  (zie  ‘Conventionele 

Werkwijze*).  Subject  Indicator  Codes 
kunnen  gebruikt  worden  voor  de 
adressering. 
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Ondersteunen  lua  officier 
indien  deze  niet  aanwezig 
is  op  brigade 

H 

BMS  /  ISIS-light 
in  combinatie  met 
Specifieke 
ontwikkelingen  en 
gebruik 

Framework 

H 

•  Bij  gebruik  van  FM9000  de  te  bieden 
functionaliteit  aanpassen  aan  de 
beschikbare  bandbreedte 

•  Aansluiten  op  BMS  ontwikkelingen 

•  Aanpassen  repHcatie  of  andere 
distributiemogelijkheden  toepassen 

Zie  ook  hoofdstuk  'Architectuur'. 

Minute-to-minute-control 

H 

Combinatie 

Framework  en 

Specifiek 

ontwikkelen 

H 

•  Aanpassen  user-interface  voor  het  snel 
en  intuitief  uit  kunnen  voeren  van  veel 
voorkomende  handelingen. 

•  Gegevens  dienen  direct  verzonden  te 
kunnen  worden. 

•  Gegevens  met  een  hoge 
(verzend)prioriteit  versturen. 

Zie  ook  hoofdstuk  'Architectuur'. 

7.2  Besluitvorming-  en  bevelvoeringsproces 

In  tegenstelling  tot  het  Airspace  Control  Proces  is  het  besluitvorming-  en 
bevelvoeringsproces  een  generiek  proces  dat  plaats  vindt  binnen  de  staven.  ISIS  is 
juist  ontwikkeld  om  deze  processen  op  legerkorps-,  divisie-  en  brigadeniveau  te 
ondersteunen. 

De  lua  participeert  in  deze  processen  en  heeft  op  een  aantal  punten  specifieke 
eisen  en  wensen.  Deze  paragraaf  behandelt  alleen  de  lua  specifieke  onderdelen  van 
het  besluitvorming-  en  bevelvoeringsproces  op  divisie-  en  brigadeniveau. 

7.2.1  Divisieniveau 

Binnen  sectie  3  (operaties)  van  de  divisiestaf  heeft  onder  andere  de  subsectie 
luchtverdediging  zitting.  Deze  subsectie  adviseert  de  divisiecommandant.  Om  de 
subsectie  in  staat  te  stellen  haar  taken  uit  te  voeren  zijn  lua-specifieke  gegevens 
benodigd.  Het  gaat  hierbij  om  specifieke  (lucht)vijandinformatie  en 
basisinlichtingen  (bijvoorbeeld  organisatiestructuur  en  beschikbare  middelen).  Op 
basis  van  deze  gegevens  wordt  een  analyse  gemaakt  van  de  luchtdreiging. 

Concreet  worden  de  volgende  overzichten  vervaardigd: 

•  overzicht  vijandelijke  luchtdreiging; 

•  prioriteiten  luchtverdediging; 

•  plan  voor  de  luchtverdediging  inclusief  altematieve  plannen. 

De  ‘derde  dimensie’  wordt  in  de  toepassing  van  het  reguliere  OBP  onvoldoende 
meegenomen  om  de  lua-officieren  in  staat  te  stellen  op  basis  hiervan  beslissingen 
te  nemen.  Dit  geldt  met  name  voor  gegevens  als  weer,  terrein  en  basisinlichtingen 
luchtvijand.  Het  is  dus  noodzakelijk  dat  de  informatie  'aangevuld'  wordt  met  lua- 
specifieke  gegevens.  Onduidelijk  is  nog  wie  de  voor  de  lua  ontbrekende  gegevens 
invoert,  beschikbaar  stelt  en  actueel  houdt.  In  het  hoofdstuk  ‘Gegevensbeheer’ 
wordt  ingegaan  op  de  extra  data-elementen  die  hiervoor  in  de  ISIS  database 
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vastgelegd  moeten  kunnen  worden.  Omdat  de  nadruk  hierbij  steeds  ligt  op 
informatievoorziening  wordt  in  de  paragraaf  ‘Overige  besturingsprocessen’  hierop 
verder  ingegaan. 

Als  resultaat  van  het  lua  specifieke  gedeelte  binnen  bet  Operationeel 
Besluitvormings  Proces  wordt  per  eigen  mogelijkheid  een  plan  ontwikkeld  ten 
behoeve  van  de  luchtverdediging.  Dit  plan  wordt  -  in  eerste  instantie  -  alleen  intern 
binnen  de  staf  gebruikt.  Na  zorgvuldige  afweging  wordt  uiteindelijk  het  ‘plan  voor 
de  luchtverdediging’  opgeleverd.  Dit  plan  wordt  in  de  bijlagen  van  het 
uiteindelijke  bevel  van  de  divisiecommandant  opgenomen. 

Voor  de  distributie  van  de  uiteindelijke  produkten  van  het  besluitvormingsproces, 
de  diverse  typen  orders  en  bevelen,  kan  gebruik  worden  gemaakt  van  de  ISIS- 
infrastructuur.  Deze  infrastructuur  is  in  principe  al  aanwezig  ten  behoeve  van  het 
generieke  OBP. 

7.2.2  Brigadeniveau 

De  batterijcomniandant  van  de  lua  fungeert  als  speciale  stafofficier 
luchtverdediging  voor  de  brigade.  Uit  dien  hoofde  neemt  hij  deel  aan  het 
besluitvormingsproces.  Op  deze  manier  sluiten  het  besluitvormingsproces  van  de 
manoeuvre  en  de  lua  beter  op  elkaar  aan  en  wordt  ook  tijdwinst  geboekt.  De 
benodigde  fiinctionaliteit  voor  de  lua-officier  ten  behoeve  van  het  besluitvorming- 
en  bevelvoeringsproces  is  gelijk  aan  die  op  divisieniveau,  zij  het  dat  de 
geografische  oppervlakte  waarop  geopereerd  wordt  kleiner  is.  Ook  deze  mobiliteit 
dient  ondersteund  te  worden.  In  het  hoofdstuk  'Architectuur'  wordt  hier  dieper  op 
ingegaan. 


7.2.3  Algemeen 

De  ondersteuning  van  het  besluitvorming-  en  bevelvoeringsproces  bestaat  -  voor 
zover  het  de  lua  betreft  -  vooral  uit  het  kunnen  maken  van  (geografische) 
overzichten  (oleaten)  en  het  opstellen  van  onderdelen  van  het  uiteindelijke  plan. 

De  geografische  activiteiten  kunnen  goed  met  behulp  van  het  huidige  GIS  - 
eventueel  aangevuld  met  de  in  paragraaf  7.1  genoemde  functionaliteit  - 
ondersteund  worden. 

Voor  het  vastleggen  en  distribueren  van  geformaliseerde  berichten  -  zoals  het 
bevel  -  kan  het  Tactical  Message  System  (TMS)  van  ISIS  gebruikt  worden  (zie 
hoofdstuk  'ISIS').  De  Subject  Indicator  Codes  (SICs)  bepalen  dan  naar  wie  het 
bericht  uiteindelijk  verstuurd  zal  worden.  De  ISIS-infrastructuur  draagt  zorg  voor 
de  fysieke  verspreiding. 

Voor  het  uitwisselen  van  ongeformateerde  en  informele  berichten  kan  rechtstreeks 
van  Email-faciliteiten  (Exchange)  gebruik  gemaakt  worden. 
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label  2:  Lua  specifieke  eisen  met  betrekking  tot  besluitvorming  en  bevelvoering  in 

relatie  tot  ISIS. 


Functionaliteit 

Prio 

Ontwikkelwijze 

Compl 

Opmerking 

Opstcllen  geografisch 
gedeelte  van  het  plan 

H 

in  ISIS  / 

met  framework 

L 

•  Toevoegen  specifieke  lua  symbolen  en 
objecten. 

Invoeren  en  ontvangen 
opdracht 

H 

in  ISIS  / 

met  framework 

L 

•  Voor  het  invoeren  van  (tekstuele 
gedeelten  van)  opdrachten  kan  gebruik 
gemaakt  worden  van  de  tools  uit  de 
Office  omgeving: 

-  Excel. 

-  Word. 

-  PowerPoint. 

•  Ter  ondersteuning  kunnen  templates 
ontwikkeld  worden. 

•  Onduidclijk  is  nog  wie  de  lua- 
specifieke  gegevens  die  gebruikt 
worden  voor  de  informatievoorziening 
invoert  en  actueel  houdt. 

Distribueren  opdracht 

H 

in  ISIS  / 

met  framework 

L 

•  Voor  distributie  kan  gebruik  gemaakt 
worden  van  de  complete  ISIS 
infrastructuur. 

•  Losse  ongestructureerde  berichten 
kunnen  m.b.v.  E-mail  verstuurd 

worden. 

•  Voor  formele  berichten  kan  het  TMS 
gebruikt  worden.  Via  Subject  Indicator 
Codes  (SICs)  wordt  dan  de  distributie 
geregeld. 

13  Overige  besturingsprocessen 

Onder  'overige  besturingsprocessen'  worden  al  die  processen  verstaan  die  het 
besluitvorming-  en  bevelvoeringsproces  ondersteunen.  Op  divisie-  en 
brigadeniveau  is  met  name  het  informatieverwervingsproces  van  belang.  In  deze 
paragraaf  wordt  onderscheid  gemaakt  tussen: 

•  vijandinformatie  /  doelinformatie; 

•  informatie  van  eigen  eenheden. 

7.3.1  Doelinformatie 

Voor  alle  niveaus  is  het  noodzakelijk  inzicht  te  hebben  in  de  vijandelijke 
luchtdreiging.  Op  lagere  niveaus  (batterij  en  lager)  is  deze  informatie  echter 
tijdkritischer  dan  op  de  hogere  niveaus  (divisie  en  brigade).  Het  luchtbeeld  is 
afkomstig  van  de  (radar)sensoren  en  wordt  aangeleverd  via  de  FM9000  (of  een 
andere  radio).  Indien  gebruik  wordt  gemaakt  van  ISIS  is  het  gewenst  dat  ook  deze 
informatie  in  een  ISIS  omgeving  gepresenteerd  wordt.  Dit  kan  de  volgende 
voordelen  opleveren: 
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•  de  gebruiker  wordt  een  consistente  gebruikersinterface  geboden; 

•  de  gegevens  kunnen  op  de  stafkaart  van  ISIS  worden  afgebeeld; 

•  de  doelinformatie  kan  samen  met  voor  de  lua  belangrijke  informatie  (ACO’s, 
posities  van  eenheden  etc.)  worden  afgebeeld; 

•  er  hoeft  geen  speciale  hardware  te  worden  aangeschaft. 

Belangrijk  gegeven  hierbij  is  dat  de  aangeleverde  luchtdoelen  elke  2  seconden 
aangeleverd  worden.  Indien  de  gegevens  op  de  standaardmanier  via  de  ISIS- 
infrastructuur  verwerkt  worden  (applicatiedatabase  -  vertaler  -  replicatiedatabase  - 
..)  kunnen  de  gegevens  niet  binnen  de  gestelde  tijd  verwerkt  worden. 

Een  andere  mogelijkheid  is  om  de  gegevens  niet  via  de  ISIS-infrastructuur  aan  te 
leveren,  maar  via  een  speciaal  gereserveerd  radionet  rechtstreeks  door  de  applicatie 
te  laten  ontvangen.  De  gegevens  worden  dan  niet  in  de  ISIS-database  vastgelegd, 
maar  aangeleverd  als  een  bestand  via  een  FM9000  verbinding.  Eenmaal 
aangeleverd  kan  het  bestand  ook  gebruikt  worden  door  andere  ISIS-clients.  Het 
ISIS-framework  wordt  dan  voomamelijk  gebruikt  voor  de  presentatie  van  de 
gegevens.  Om  na  te  gaan  of  het  gebruik  van  ISIS  onderdelen  een  haalbaar 
altematief  is,  zijn  testen  uitgevoerd  waarbij  vooral  de  performance  van  de  grafische 
onderdelen  van  ISIS  is  gemeten.  In  het  hoofdstuk  'Architectuur'  wordt  hier  dieper 
op  ingegaan.  Gebleken  is  dat  het  presenteren  van  30  doelen  binnen  2  seconden 
mogelijk  is.  Om  een  en  ander  mogelijk  te  maken  dienen  de  volgende  onderdelen 
ontwikkeld  te  worden  (voor  een  aantal  onderdelen  kan  een  gedeelte  van  het 
framework  gebruikt  worden): 

•  proces  dat  de  doelinformatie  via  de  FM9000  in  de  PC  invoert; 

•  proces  in  het  ISIS-GIS  dat  deze  gegevens  inleest  en  in  een  speciaal  te 
ontwikkelen  oleaat  op  een  geografische  achtergrond  presenteert; 

•  proces  dat  een  aantal  geografische  operaties  versnelt. 


ISIS  clients 


De  doelinformatie  wordt 
geintegreerd  met  C2- 
gegevens  zoals  ACO's 
en  posities  van  de  een¬ 
heden  en  gepresenteerd 
op  een  ISIS-station. 

Figuur  17:  Doelinformatie  gecombineerd  met  C2-gegevens  weergeven  op  een  ISIS- 
station. 
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Op  het  ’doelinformatie-station’  kunnen  ook  de  normale  objecten  (ACO’s,  positie 
eigen  eenheden,  vakgrenzen  etc.)  afgebeeld  worden.  Ook  zoomen  en  verschuiven 
van  de  kaart  is  mogelijk.  Het  is  mogelijk  om  de  reguliere  werkzaamheden  op  het 
station  uit  te  voeren.  Voor  het  afbeelden  van  het  luchtbeeld  wordt  aanbevolen  een 
separaat  scherm  te  reserveren  (totaal  dus  twee  schermen  op  een  station). 

Vijandinformatie  bestaat  ook  uit  gegevens  afkomstig  van  inlichtingenbronnen:  welk 
materieel  heeft  de  vijand,  in  welke  aantallen,  en  hoe  is  de  gevechtsorganisatie. 
Gegevens  over  het  personeel  en  materieel  worden  in  ISIS-terminologie  de  'Holding' 
genoemd.  Hoewel  deze  functionaliteit  in  eerdere  versies  van  ISIS  aanwezig  is 
geweest,  was  dit  niet  het  geval  in  de  laatste  versie  (juni  1998).  Voor  de 
gevechtsorganisatie  is  binnen  ISIS  de  ORBAT-browser  ontwikkeld. 

7.3.2  Informatie  van  eigen  eenheden 

De  informatievoorziening  vindt  op  het  laagste  niveau  plaats  doordat 
wapensystemen  rapportages  (periodiek)  en  meldingen  (incidenteel)  doorgeven  aan 
de  (pelotons)commandant.  Op  het  batterijniveau  worden  deze  gegevens 
geaggregeerd  en  aan  het  hogere  niveau  (brigade  /  divisie)  doorgegeven. 

Een  groot  gedeelte  van  de  meldingen  kan  op  een  geografische  achtergrond 
geprojecteerd  worden  en  wordt  met  behulp  van  het  huidige  ISIS  al  ondersteund. 
Eventueel  kan  voor  ongestructureerde  meldingen  het  TMS  gebruikt  worden. 

In  hoofdstuk  5  (Database)  is  al  aangegeven  dat  veel  functionaliteit  ondersteund  kan 
worden  door  de  'Action'  gtxtXdXttr At  gegevens  te  ondersteunen  in  de  applicatie.  In 
dat  geval  komen  veel  gegevens  van  de  eigen-  en  vijandelijke  eenheden  samen  en 
kan  achterhaald  worden  welke  eenheid  een  vijand  heeft  waargenomen,  welke  actie 
daarop  is  uitgevoerd  met  welke  middelen  en  wat  het  (tijdelijke  en  eind)  resultaat 
hiervan  is.  Daarnaast  kunnen  de  door  de  vijand  genomen  acties  worden  vastgelegd. 
Deze  gegevens  kunnen  weer  gebruikt  worden  bij  het  reconstrueren  van  het  gevecht 
en  bij  het  opbouwen  van  het  vijand-beeld  (doctrine). 
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Tabel  3:  Besluitvorming,  bevelvoering  en  informatievoorziening. 


Functionaliteit 

Prio 

Ontwikkelwijze 

Compl 

Opmerkinff 

Actueel  overzicht  huidige 
situatie 

H 

in  ISIS 

met  framework 

L 

•  Locatie  en  status  van  eenheden  is 
binnen  ISIS  al  toegankelijk. 

•  Voorzieningen  moeten  aangebracht 
worden  om  de  gebruiker  duidelijk  te 
maken  hoe  actueel  de  informatie  die  hij 
nu  tot  zijn  beschikking  hecft  is  (per 
replicatienode). 

Gevechtsorganisatie 

H 

in  ISIS 

- 

•  Complete  functionaliteit  is  al  aanwezig 
binnen  ISIS. 

Gegevens  over  personeel 
/  materieel 

H 

met  framework 

L 

♦  De  benodigde  gegevens  zijn 
opgenomen  in  het  ISIS- 
applicatiemodel. 

•  Functionaliteit  was  in  eerdere  versies 
onderdeel  van  de  GIS-applicatie.  In  de 
laatste  versie  niet  meet. 

Doelinformatie 

H 

met  framework 

M 

•  Versnellen  grafische  acties 

•  Presenteren  doelgegevens  (vector  en 
identificatie) 

•  Gegevens  via  andere  weg  dan  database 
inlezen. 

•  Omzetten  doelgegevens  in  GIS- 
objecten. 

specifiek 

ontwikkelen 

M 

•  Proces  voor  invoer  van  doelinformatie 
via  de  FM9000 

Rapportages  en 
meldingen 

H 

in  ISIS 

•  Gegevens  kunnen  met  behulp  van  het 
ISIS-GIS  worden  ingevoerd. 

•  Contracten  dienen  ervoor  te  zorgen  dat 
de  gegevens  naar  de  juiste  eenheden 
worden  verspreid. 

Actie  gerelateerde 
functionaliteit 

M-H 

met  framework 

M-H 

Indien  deze  functionaliteit  in  de  applicatie 
ingebouwd  gaat  worden  kunnen  complete 
acties  ondersteund  worden.  Vastgelegd  kan 
dan  onder  andere  worden: 

•  Wie  heeft  welke  vijand  waargenomen. 

•  Welke  middelen  zijn  nodig  om  de 
vijand  te  bestrijden 

•  Wie  heeft  de  vijand  bestreden. 

•  Met  welke  middelen. 

•  Met  welk  (tussen/eind)resultaat. 

•  Welke  acties  heeft  de  vijand 
uitgevoerd. 

De  benodigde  gegevens  zijn  al  in  het  ISIS- 
datamodel  (uitwisselmodel)  opgenomen 
(niet  in  het  applicatiemodel).  Er  is  echter 
nog  geen  applicatiefunctionaliteit  aanwezig 
om  hier  gebruik  van  te  maken. 
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7.4  Samenvatting 
Airspace  Control 

Voor  de  lua  heeft  Airspace  Control  de  hoogste  prioriteit.  Een  groot  gedeelte  van  de 
gewenste  functionalteit  bestaat  uit  het  creeren  van  orders  (ACO’s)  en  bevelen. 

Voor  minute-to-minute-control  is  het  daamaast  noodzakelijk  dat  gegevens  snel  en 
onder  tijdsdruk  ingevoerd  moeten  kunnen  worden  en  dat  deze  met  de  hoogst 
prioriteit  verzonden  kunnen  worden. 

Veel  van  de  gewenste  functionaliteit  bestaat  uit  (geo)grafische  manipulaties  op  een 
stafkaart.  In  al  deze  situaties  zal  het  gebruik  van  het  ISIS-framework  veel 
ontwikkelwerk  besparen. 

Om  te  kunnen  garanderen  dat  onder  vrijwel  alle  omstandigheden  doorgewerkt  kan 
worden  (en  om  aan  te  kunnen  sluiten  bij  buitenlandse  eenheden)  is  het 
noodzakelijk  dat  ACO's  ook  op  de  oude  manier  gebruikt  kunnen  worden.  Deze 
situatie  vertoont  veel  overeenkomsten  met  de  binnen  ISIS  ontwikkelde  HEROS- 
gateway.  Het  gebruik  hiervan  kan  veel  ontwikkelwerk  besparen. 

Om  de  lua-officier  te  ondersteunen  op  zowel  de  brigade-  als  de  batterij-cp  dient 
aansluiting  gezocht  te  worden  met  het  C2-systeem  voor  de  lagere  tactische  niveaus 
(BMS).  In  het  hoofdstuk  Architectuur  wordt  hier  dieper  op  ingegaan. 

Besluitvorming  en  bevelvoering 

ISIS  is  met  name  ontwikkeld  om  deze  processen  op  brigade-  en  divisieniveau  te 
ondersteunen.  De  lua  stelt  een  aantal  specifieke  eisen  op  het  gebied  van  het 
vervaardigen  van  overzichten  en  plannen.  Deze  hebben  vooral  betrekking  op  het 
ondersteunen  van  informatie  met  betrekking  tot  de  derde  dimensie.  De  gewenste 
functionaliteit  is  voor  het  grootste  gedeelte  al  aanwezig  binnen  in  ISIS  of  kan 
eenvoudig  met  behulp  van  het  ISIS-framework  ontwikkeld  worden. 

Overige  besturingsprocessen 

Het  presenteren  van  doelinformatie  wordt  momenteel  niet  ondersteund  in  ISIS. 
Testen  hebben  uitgewezen  dat  het  presenteren  van  deze  gegevens  binnen  de 
gestelde  eisen  mogelijk  is.  Het  ontwikkelen  van  deze  functionaliteit  kost  relatief 
weinig  inspanning. 

Voor  het  volgen  van  het  complete  gevecht  is  binnen  het  ISIS-datamodel  de 
zogenoemde  Acrion-constructie  aanwezig  (zie  ook  hoofdstuk  TICCS-  versus  ISIS- 
gegevens).  Hiermee  kan  bijvoorbeeld  vastgelegd  worden: 

•  wie  welke  vijand  heeft  waargenomen; 

•  wat  heeft  de  vijand  voor  actie  ondemomen; 

•  welke  middelen  nodig  zijn  om  de  vijand  te  bestrijden; 

•  wie  heeft  de  vijand  uiteindelijk  bestreden; 

•  met  welke  middelen; 

•  en  met  welk  tussen-  en  eindresultaat. 
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De  constructie  biedt  een  krachtige  manier  om  inzage  te  krijgen  in  de  voortgang  en 
resultaten  van  het  gevecht,  mils  de  benodigde  gegevens  actueel  gehouden  worden. 
Er  is  echter  nog  geen  functionalteit  in  het  ISIS-GIS  aanwezig  om  hiervan  gebruik 
te  maken.  Afhankelijk  van  de  exacte  invulling  van  de  gewenste  functionaliteit  kan 
de  realisatie  ervan  redelijk  tot  veel  ontwikkelinspanning  vergen.  Ook  in  dit  geval 
kan  gebruik  gemaakt  worden  van  het  ISIS-framework. 
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8.  Architectuur 


In  deze  paragraaf  wordt  ingegaan  op  technische  en  systeemspecifieke  aspecten  die 
samenhangen  met  de  architectuur  in  het  geva!  dat  ISIS  wordt  toegepast  voor 
TICCS.  Aan  de  orde  komen: 

•  Rexibiliteit; 

•  Robuustheid  ,  betrouwbaarheid  en  actualiteit; 

•  Communicatie  tussen  brigade  en  batterij; 

•  Performance. 


8.1  Flexibiliteit 

De  flexibiliteit  van  de  TICCS  /  ISIS  configuratie  wordt  ondermeer  bepaald  door  de 
manier  waarop  met  andere  legeronderdelen  en  buitenlandse  eenheden  kan  worden 
samengewerkt  en  de  mogelijkheden  die  geboden  worden  om  sessies  en  contracten 
tussen  knooppunten  op  te  zetten. 

8.1.1  Samenwerking  met  andere  legeronderdelen  en  buitenlandse 
eenheden 

De  lua  maakt  altijd  onderdeel  uit  van  andere  legeronderdelen.  De  configuratie 
moet  dus  voldoende  flexibel  zijn  om  dit  toe  te  laten.  Daamaast  moet  het  mogelijk 
zijn  om  samen  te  werken  met  andere  nationaliteiten. 

Indien  de  legeronderdelen  waarmee  de  lua  samenwerkt  al  de  beschikking  hebben 
over  ISIS  dan  kan  hiervan  gebruik  gemaakt  worden.  De  lua  clients  kunnen  in  dat 
geval  op  de  al  aanwezige  server  worden  aangesloten.  Wei  dienen  op  de 
replicatieserver  specifieke  contracten  afgesloten  te  worden  met  de  partijen 
waarvan  de  lua  de  informatie  wenst  te  ontvangen  en  viceversa.  Momenteel  wordt  - 
hoewel  deze  functionaliteit  is  ingebouwd  -  binnen  ISIS  nog  geen  gebruik  gemaakt 
van  filtering  bij  replicatie.  Dit  wordt  veroorzaakt  door  de  volgende  factoren: 

•  de  tot  nu  toe  gehouden  oefeningen  zijn  relatief  kort  van  tijdsduur  en  er  zijn 
daardoor  weinig  historische  gegevens; 

•  het  aantal  actieve  nodes  is  relatief  klein  (tot  nu  toe  maximaal  4); 

•  alle  gebruikers  zijn  geinteresseerd  in  dezelfde  soort  gegevens; 

•  er  is  -  door  het  gebruik  van  ZODIAC  -  momenteel  voldoende  bandbreedte 
beschikbaar. 

Het  gevolg  is  dat  momenteel  alle  gegevens  van  de  gespecificeerde  eigenaar  via 
replicatie  verstuurd  worden. 

Op  legerkorps  niveau  is  een  koppeling  naar  HEROS  voorzien.  Hiermee  is  het 
mogelijk  om  HEROS  berichten  uit  te  wisselen  met  ISIS  en  viceversa  (zie  ook 
hoofdstuk  ISIS).  Momenteel  kunnen  own-  en  enemy-sitreps  van  het  ADatP-3 
berichtenformaat  worden  vertaald.  De  HEROS-ISIS  vertaling  wordt  momenteel 
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uitgevoerd  op  legerkoqjsniveau.  Het  is  nog  niet  duidelijk  of  de  HEROS-ISIS 
interface  in  de  toekomst  ook  op  andere  niveaus  zal  worden  toegepast. 

Indien  wordt  samengewerkt  met  buitenlandse  eenheden  die  ATCCIS-compliant 
zijn  dient  hiervoor  een  ATCCIS-ISIS  vertaler  te  worden  ontwikkeld.  Daamaast  zal 
een  specifieke  database  met  het  ATCCIS  datamodel  en  een  ATCCIS 
replicatiemechanisme  aanwezig  moeten  zijn  om  met  andere  ATCCIS  knooppunten 
te  kunnen  communiceren.  Een  gedeelte  van  de  benodigde  functionaliteit  is  in  het 
kader  van  een  ATCCIS-evaluatie  al  ontwikkeld  en  met  succes  toegepast;  de 
configuratie  is  echter  nog  niet  operationeel  gebruikt.  In  de  volgende  fase  van  het 
ATCCIS  project  (tweede  helft  1998)  zal  de  aandacht  uitgaan  naar  verdere 
operationalisering  van  het  ATCCIS  concept. 

8.1.2  Configuratie 

In  de  paragraaf  'Communicatie'  is  al  ingegaan  op  de  contracten  tussen  legerkorps, 
divisie  en  brigade  en  de  gevolgen  voor  de  verbindingsmiddelen.  Deze  paragraaf  zal 
zich  met  name  richten  op  de  communicatie  met  het  batterijniveau. 

De  lua-batterij  wordt  op  de  brigade  permanent  vertegenwoordigd  door  de  liaison- 
officier  (twee  man  voor  fulltime  bemanning).  BiJ  belangrijke  beslissingen  is  de 
batterijcommandant  ook  aanwezig  (speciale  stafofficier).  Op  zowel  de  brigade  als 
de  batterij  dient  de  batterijcommandant  de  beschikking  te  hebben  over  dezelfde 
functionaliteit.  Het  is  niet  noodzakelijk  dat  deze  functionaliteit  ook  onderweg 
tussen  brigade  en  batterij  beschikbaar  is.  Als  eis  geldt  dat  de  functionaliteit  te  alien 
tijde  beschikbaar  moet  zijn;  ook  als  de  communicatiemiddelen  zijn  uitgevallen.  In 
dat  geval  dienen  de  gegevens  gedistribueerd  te  worden  als  de  verbinding  is 
hersteld.  De  communicatie  tussen  de  brigade  en  de  divisie  verloopt  over  een 
ZODIAC  verbinding.  Tussen  brigade  en  batterij  is  slechts  een  FM9000  verbinding 
beschikbaar.  Hieronder  volgt  een  aantal  mogelijke  oplossingen  om  de 
batterijcommandant  in  deze  situatie  te  ondersteunen  (over  de  koppeling  tussen  C2- 
systemen  op  brigade  en  batterijniveau  later  meer): 


TNO-rapport 


FEL-98-A245 


79 


1. 


(Portable  C2-station  ver- 
bonden  met  FM9000) 


Figuur  18:  Twee  vaste  werkstations. 

De  lua-officier  heeft  twee  werkstations;  een  die  vast  is  gemstalleerd  op  de 
brigade-CP  en  -  door  middel  van  de  ISIS-infrastructuur  -  is  verbonden  met 
het  ZODIAC  network.  Het  tweede  workstation  is  continu  verbonden  met  de 
FM9000  en  wordt  gevoed  door  de  brigade.  Als  de  lua-officier  aanwezig  is 
op  de  brigade  wordt  het  vaste  workstation  gebmikt.  Omdat  hier  sprake  is 
van  een  breedbandige  verbinding  kan  hier  door  volledige  datareplicatie  alle 
informatie  beschikbaar  worden  gesteld.  Indien  de  lua-officier  op  de  batterij 
aanwezig  is  wordt  gebruik  gemaakt  van  het  workstation  dat  verbonden  is 
met  de  FM9000.  Omdat  hier  minder  bandbreedte  beschikbaar  is,  zal  ook 
mogelijk  minder  informatie  geboden  kunnen  worden  (bijv.  door  inperken 
van  contracten).  Momenteel  is  nog  onduidelijk  hoe  deze  C2-functionaliteit 
onder  brigadeniveau  gerealiseerd  zal  worden.  Het  werken  met  twee 
werkstations  heeft  ook  gevolgen  voor  andersoortige  gegevens  (bijvoorbeeld 
documenten);  de  lua-officier  moot  continu  alert  blijven  welke  gegevens  op 
welk  station  aanwezig  zijn  (ook  hiervoor  zijn  tools  aanwezig,  maar  deze 
doen  een  aanslag  op  de  toch  al  beperkte  bandbreedte).  Binnen  dit 
altematief  kunnen  de  contracten  op  twee  mogelijke  manieren  geregeld 
worden: 

1 .  Er  wordt  gebruik  gemaakt  van  contract-forwarding;  met  andere 
woorden  het  knooppunt  op  de  brigade  forward  (stuurt)  de  gegevens 
automatisch  naar  de  batterij. 

2.  Er  wordt  gebruik  gemaakt  van  het  ACP/RCP-concept;  met  andere 
woorden  er  is  steeds  een  station  actief  en  als  de  lua-officier  over  wil 
stappen  naar  het  andere  station  moet  dit  volgens  de  ACP/RCP 
procedure  (geschatte  tijdsduur:  1  tot  5  minuten). 


In  beide  gevallen  heeft  dit  gevolgen  voor  de  afgesloten  contracten  van  en 
naar  de  brigade  /  batterij. 

Om  dit  altematief  toe  te  kunnen  passen  dient  server-to-server-replicatie  via 
de  FM90(X)  gerealiseerd  te  worden. 


(Portable  C2-statjon  ver- 
bonden  met  FM9000) 


Figuur  19:  Hetzelfde  werkstation  wordt  gehruikt  op  de  brigade  en  batterij. 

De  lua-officier  heeft  een  werkstation  en  neemt  dat  mee  van  de  batterij 
naar  de  brigade.  In  het  geval  dat  de  officier  bij  de  brigade  is  wordt  bet 
werkstation  gekoppeld  aan  de  server  op  de  brigade.  Doordat  hier 
gebruik  gemaakt  wordt  van  het  ZODIAC-netwerk  kan  de  complete  ISIS 
functionaliteit  geboden  worden.  Bij  aankomst  op  de  batterij  wordt  het 
werkstation  aangesloten  op  de  FM90(X)  configuratie.  Omdat  hier 
minder  bandbreedte  aanwezig  is  zullen  ook  de  afgesloten  contracten  in 
omvang  kleiner  zijn.  Wordt  nu  een  ISIS  applicatie  op  dezelfde  client 
opgestart,  dan  zal  blijken  dat  er  minder  gegevens  in  de  database 
aanwezig  zijn. 

Om  dit  altematief  toe  te  kunnen  passen  dient  ook  server-to^server 
replicatie  via  de  FM9000  gerealiseerd  te  worden  en  zal  het 
replicatieprotocol  op  enkele  punten  aangepast  moeten  worden.  Het 
voordeel  is  dat  de  gebmiker  met  een  en  hetzelfde  werkstation  werkt. 
Bovendien  kan  de  lua  met  dit  losse  werkstation  ook  opereren  op 
commandoposten  van  niet-Nederlandse  eenheden,  mits  deze  via  de 
FM9000  bereikbaar  zijn. 
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3. 


Figuur  20:  Cl-station  is  vast  verhonden  met  de  FM9000. 

De  lua-officier  heeft  een  vast  werkstation  dat  altijd  verbonden  is  met  de 
FM90(X).  Binnen  dit  altematief  zijn  ook  twee  mogelijkheden  aanwezig: 

a)  de  lua-officier  beschikt  over  een  complete  ISIS-configuratie  (client 
en  server). 

b)  de  lua-officier  beschikt  alleen  over  een  client;  de  server  is  aanwezig 
op  de  CP  van  de  brigade. 

Bij  altematief  a  kan  de  lua-officier  ook  (met  de  ISIS-database)  werken 
indien  de  FMQOOO  verbinding  tijdelijk  niet  beschikbaar  is.  Altematief  b 
gebmikt  de  FMQOOO  als  een  Verlenging’  van  het  netwerk  tussen  de 
client  en  de  server.  Steeds  als  de  applicatie  gegevens  uit  de  database 
nodig  heeft  zullen  deze  met  behulp  van  de  FM90{X)  opgehaald  worden. 
Er  is  in  dit  geval  een  grote  afhankelijkheid  van  de  FM90()0  en  de 
applicatie  zal  aangepast  moeten  worden  om  tijdelijke  netwerk- 
onderbrekingen  op  te  kunnen  vangen.  Ook  dient  de  FM9()00  als 
’modem'  gebmikt  te  kunnen  worden.  Indien  altematief  a  wordt 
toegepast  dient  eveneens  server-to-server  communicatie  over  de 
FM9()00  te  worden  toegepast.  Bij  altematief  b  wordt  de  FM9()00  als 
een  draadloos  modem  gebmikt. 


BMS  /  ISIS-light  oplossing.  Het  is  nog  onduidelijk  welke 
ontwikkelingen  plaats  zullen  vinden  op  het  gebied  van  BMS  /  ISIS- 
light.  Mogelijk  wordt  vanuit  deze  richting  een  oplossing  aangedragen 
voor  de  beschreven  problematiek. 
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In  de  genoemde  altematieven  geldt  steeds  dat  server-to-server  communicatie  over 
de  FM9000  voor  replicatie  gerealiseerd  moet  worden.  Het  is  nog  onduidelijk  welke 
protocollen  en  berichtenuitwisselingssystemen  (bijv.  Exchange)  hiervoor  gebruikt 
gaan  worden.  In  de  huidige  ISIS-configuratie  is  het  niet  mogelijk  om  replicatie  over 
FM9000  uit  te  voeren. 

Bij  het  gebruik  van  twee  verschillende  stations  kunnen  problemen  ontstaan  als  het 
station  ook  voor  andere  doeleinden  wordt  gebruikt  (documenten,  bevelen  etc.).  Ook 
in  de  Request  for  Information’2  [20]  wordt  uitgegaan  van  een  werkstation  (indien 
mogelijk  met  twee  beeldschermen).  Een  werkstation  verdient  daarom  de  voorkeur 
(alternatief  1  valt  af).  Omdat  gesteld  is  dat  de  lua-officier  onderweg  tussen  de 
brigade  en  de  batterij  niet  over  een  operationeel  werkstation  hoeft  te  beschikken 
valt  ook  alternatief  3  af. 

Uiteindelijk  zal  een  koppeling  met  het  commandovoeringssysteem  voor  de  lagere 
niveaus  gerealiseerd  moeten  worden.  Pas  dan  zal  blijken  of  alternatief  2  en 
alternatief  4  gecombineerd  kunnen  worden. 


8.2  Robuustheid^  betrouwbaarheid  en  actualiteit 

8.2.1  Uitval  van  componenten 

Voor  de  lua  is  het  -  op  legerkorps-,  divisie-,  en  brigadeniveau  -  van  groot  belang  dat 
ACO’s  op  een  betrouwbare  en  snelle  manier  gedistribueerd  kunnen  worden.  Indien 
hiervoor  ISIS  wordt  gebruikt  moet  zeker  gesteld  worden  dat  de  distributie  ook  door 
kan  gaan  als  een  knooppunt  of  een  gedeelte  ervan  uitgevallen  is. 


In  het  geval  een  onderdeel  van  een  knooppunt  uitvalt  zijn  er  op  hoofdniveau  drie 
situaties  te  onderscheiden: 


ZODIAC 


1:  Clients 


2:  Server 


3:  Datacommunicatie 


Figuur  21:  Componenten  die  mogelijk  uit  kunnen  vallen. 
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1 .  De  ISIS-client  is  niet  meer  operationeeL 

Deze  situatie  geeft  de  minste  complicaties.  Vooropgesteld  dat  er  altijd  een 
geconfigureerde  reserve-client  voorhanden  is  (die  zo  mogelijk  al  is  opgenomen 
in  het  netwerk),  kan  deze  zonder  verdere  complicaties  ingezet  worden.  Van 
belang  is  dat  de  reserve-client  continu  voorzien  wordt  van  de  laatste 
softwareversies.  Alle  dynamische  gegevens  worden  in  de  ISIS  database 
vastgelegd  en  zijn  meteen  weer  toegankelijk  op  de  nieuwe  client;  alleen 
‘persoonlijke’  instellingen  zoals  de  invulling  en  kleur  van  objecten  zijn  lokaal 
op  de  client  vastgelegd  en  zullen  eventueel  opnieuw  ingesteld  moeten  worden. 

2.  De  ISIS-server  is  niet  meer  operationeeL 

De  ISIS-server  kan  verspreid  zijn  over  verschiUende  fysieke  systemen:  de 
database-server  en  de  replicatieserver.  Om  uitval  van  de  systemen  zo  goed 
mogelijk  op  te  vangen  dienen  ‘rampenscenario’s’  ontwikkeld  te  worden  waarin 
stap  voor  stap  uiteen  wordt  gezet  hoe  de  configuratie  weer  zo  snel  mogelijk 
operationeel  kan  worden  gemaakt.  Voor  een  aantal  ISIS-componenten  wordt 
hier  momenteel  aan  gewerkt. 

In  situaties  waarin  de  continui’teit  van  essentieel  belang  is  dienen  zoveel 
mogelijk  preventieve  maatregelen  genomen  te  worden.  Hierbij  valt  te  denken 
aan  specifieke  hardware- systemen  waarvan  belangrijke  componenten  dubbel 
zijn  uitgevoerd  of  systemen  die  op  de  achtergrond  continu  ‘schaduw  draaien’ 
en  bij  een  storing  snel  inzetbaar  gemaakt  kunnen  worden. 

3.  De  communicatiemiddelen  zijn  niet  meer  operationeel. 

Onder  het  uitvallen  van  de  communicatiemiddelen  wordt  in  dit  geval  verstaan 
het  uitvallen  van  de  communicatiemiddelen  tussen  twee  ISIS-servers. 

Als  een  gedeelte  van  de  beschikbare  (ZODIAC)  bandbreedte  niet  meer 
beschikbaar  is  kan  teruggevallen  worden  op  een  lagere  bandbreedte.  Indien  de 
volledige  bandbreedte  is  weggevallen,  dan  kan  in  het  uiterste  geval 
teruggevallen  worden  op  de  conventionele  werkwijze:  het  'met  de  hand' 
transporteren  van  de  gegevens  via  een  medium,  bijvoorbeeld  een  diskette. 
Airspace  Control  Orders  dienen  in  dat  geval  gegenereerd  te  kunnen  worden  uit 
oleaten  die  met  behulp  van  het  GIS  zijn  ontwikkeld  (of  rechtstreeks  uit  de 
database  overgenomen  te  worden).  De  -  tekstuele  -  uitvoer  kan  dan  op 
alternatieve  manieren  naar  de  belanghebbenden  worden  verspreid.  Op  het 
ontvangende  knooppunt  kunnen  de  gegevens  vervolgens  worden  ingelezen. 

Een  probleem  vormt  hierbij  wel  dat  de  eigenaar  van  de  gegevens  niet  meer  juist 
is,  hetgeen  gevolgen  kan  hebben  voor  de  bestaande  replicatiecontracten. 
Hiervoor  zullen  oplossingen  gezocht  moeten  worden  (bijvoorbeeld  de  mutaties 
rechtstreeks  uitvoeren  op  de  database,  dus  niet  onder  de  owner-id  van  de 
gebmiker  zelf). 

In  het  geval  dat  bij  communicatie  tussen  twee  knooppunten  gebruik  wordt 
gemaakt  van  een  tussenstation  en  dit  tussenstation  valt  uit,  dan  zal  automatisch 
zoveel  mogelijk  naar  alternatieve  routering  worden  gezocht  zodat  het 
knooppunt  wellicht  op  een  alternatieve  manier  bereikt  kan  worden. 
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In  deze  paragraaf  is  met  name  ingegaan  op  het  uitvallen  van  componenten  zoals  die 
nu  in  een  ISIS-configuratie  zijn  opgenomen.  De  consequenties  van  het  uitvallen 
van  C2'functionaliteit  onder  brigadeniveau  is  sterk  afhankelijk  van  de  C2- 
ontwikkelingen  onder  brigadeniveau  (BMS  /  ISlS-light  /  ,.)• 

8.2.2  Betrouwbaarheid  en  actualiteit  van  de  gegevens 
De  betrouwbaarheid  van  de  gegevens  is  in  de  eerste  plaats  afhankelijk  van 
correctheid  waarmee  de  gegevens  op  de  bron  worden  ingevoerd. 

Een  ander  aspect  van  betrouwbaarheid  hangt  samen  met  de  actualiteit  van  de 
gegevens;  met  andere  woorden:  'hoe  weet  ik  zeker  dcit  de  getoonde  infonnatie 
daadwerkelijk  de  meest  actuele  situatie  weergeeft  en  dat  alle  knooppimten  die  cum 
mij  gegevens  aanleveren  nog  steeds  actiefzijn  \  Om  hierop  antwoord  te  geven  is 
het  nodig  dat  knooppunten  periodiek  een  'Sign  of  life'  signaal  geven,  zodat 
nagegaan  kan  worden  hoe  actueel  de  gegevens  van  dat  knooppunt  zijn.  Binnen  ISIS 
is  hier  ook  aandacht  aan  geschonken  en  dit  heeft  geresulteerd  in  een  concept 
waarbij  replicatie-servers  elkaar  periodiek  een  'Sign  of  life'  bericht  sturen.  Indien 
dit  bericht  niet  binnen  een  bepaalde  tijd  wordt  ontvangen  duidt  dit  op  een  storing 
en  wordt  de  beheerder  hiervan  op  de  hoogte  gebracht,  zodat  belanghebbenden 
hiervan  in  kennis  gesteld  kunnen  worden  en  passende  maatregelen  kunnen  nemen. 


8.3  Communicatie  tussen  brigade  en  batterij 

Zoals  vermeld  is  momenteel  nog  onduidelijk  welke  configuratie  op  batterijniveau 
toegepast  gaat  worden.  Duidelijk  is  wel  dat  gegevensuitwisseling  tussen  het 
batterijniveau  en  brigadeniveau  mogelijk  moet  zijn  en  dat  de  beschikbare 
bandbreedte  beperkt  is  bij  toepassing  van  FM9000. 


Figuur22:  Communicatie  tussen  brigade  en  batterij. 


Ongeacht  welk  systeem  op  batterijniveau  toegepast  gaat  worden;  er  zal  een 
'vertaalslag'  moeten  plaatsvinden  tussen  brigade-  en  batterijniveau. 

In  het  geval  dat  ISIS  wordt  gebruikt  als  basis  voor  het  C2  systeem  op 
batterijniveau  zal  de  huidige  ISIS-configuratie  op  de  volgende  punten  aangepast 
moeten  worden  om  te  voldoen  aan  de  specifieke  kenmerken  onder  brigadeniveau 
(lage  bandbreedte,  beperkte  informatiebehoefte,  tijdkritische  activiteiten). 
Benadrukt  wordt  dat  dit  de  consequenties  zijn  van  het  doorvoeren  van  ISIS  op  de 
‘lagere  tactische  niveaus’.  Zie  hiervoor  ook  het  document  ‘Lichtgewicht 
Replicatie’  [16]: 

1 .  Het  'strippen'  van  het  uitwisselmodel,  omdat  niet  alle  entiteiten  /  attributen  op 
batterijniveau  nodig  zijn. 

2.  Vereenvoudigen  van  de  replicatieprotocollen. 

3.  Broadcasting  van  gegevens:  Als  een  eenheid  gegevens  verstuurd,  dan  kunnen 
meer  andere  eenheden  gelijktijdig  deze  gegevens  ontvangen  (veelal  zullen  ze 
dezelfde  contracten  hebben).  De  bandbreedte  wordt  dan  efficienter  benut. 
Replicatieprotocollen  zullen  hiervoor  aangepast  moeten  worden.  Het  is  de 
vraag  of  er  voor  elk  replicatiebericht  een  bevestiging  van  ontvangst 
teruggestuurd  moet  worden.  Het  weglaten  hiervan  zal  de  performance  ten 
goede  komen. 

4.  Geen  (of  beperkte)  historische  gegevens  bijhouden. 

5.  Gebruik  maken  van  filtering,  zodat  niet  relevante  gegevens  niet  verstuurd 
worden. 

6.  Comprimeren  van  gegevens  voordat  deze  verstuurd  worden.  Eventueel  kunnen 
gegevens  sterk  gecodeerd  verstuurd  worden.  Ook  dit  zou  een  wijziging  van  de 
replicatieprotocollen  betekenen. 

7.  Replicatie  (of  eigenlijk  de  communicatielaag)  zodanig  aanpassen  dat  rekening 
wordt  gehouden  met  vaak  uitvallende  netwerkverbindingen  (bijvoorbeeld  het 
fragmenteren  van  grote  data  pakketjes  in  kleinere  pakketjes  en  het  niet 
meesturen  van  irrelevante  gegevens). 

8.  Meer  dynamische  infrastructuur  toestaan.  De  infrastructuur  binnen  ISIS  gaat 
uit  van  vast  opgestelde  knooppunten  die  vooraf  bekend  moeten  zijn.  Voor 
lagere  niveaus  is  hier  meer  flexibiliteit  gewenst. 


8.4  Performance 

Over  de  performance  van  het  systeem  als  geheel  is  geen  eenduidige  uitspraak  te 
doen.  De  eisen  die  aan  de  performance  gesteld  worden  zijn  afhankelijk  van  de 
situatie.  Voor  minute-to-minute-control  worden  hogere  eisen  gesteld  dan  voor  het 
uitwisselen  van  bijvoorbeeld  een  initieel  plan. 


TNO- rapport 


66 


FEL-98-A245 


In  deze  paragraaf  wordt  ingegaan  op  de  volgende  aspecten  die  samenhangen  met 
performance: 

•  binnen  welk  tijdsbestek  kunnen  sessies  opgezet  worden; 

•  binnen  welk  tijdsbestek  kunnen  contracten  opgezet  worden; 

•  wat  is  de  performance  onder  operationele  omstandigheden; 

•  wat  zijn  de  gevolgen  indien  een  knooppunt  tijdelijk  onbereikbaar  is; 

•  hoeveel  tijd  kost  het  omzetten  van  gegevens  tussen  ISIS  en  HEROS; 

•  wat  zijn  de  mogelijkheden  met  betrekking  tot  het  stellen  van  prioriteiten; 

•  in  hoeverre  kan  (een  gedeelte  van)  ISIS  worden  gebruikt  voor  het  afbeelden 
van  de  doelinformatie. 

Tenslotte  wordt  ingegaan  op  punten  waar  mogelijke  performanceverbetering  kan 
worden  bereikt. 

8.4.1  Het  opzetten  van  een  sessie 

Een  sessie  wordt  opgezet  tussen  twee  knooppunten  en  is  bedoeld  om  gedurende 
langere  tijd  (langer  dan  een  dag)  actief  te  blijven.  Zolang  de  verbinding  tussen 
twee  knooppunten  in  stand  wordt  gehouden  is  het  niet  nodig  de  sessie  af  te  breken. 
Het  opzetten  van  een  sessie  gaat  in  de  regel  gepaard  met  het  opzetten  van  een 
contract.  Als  er  geen  contracten  meer  zijn  kan  de  sessie  worden  afgebroken. 

8.4.2  Het  opzetten  van  een  contract 

Als  een  sessie  tussen  twee  knooppunten  tot  stand  is  gebracht  worden  contracten 
afgesloten.  Er  is  momenteel  een  keuze  uit  voorgedefinieerde  contracten,  maar  in  de 
toekomst  kunnen  ook  nieuwe  contracten  aangemaakt  worden.  Voor  elk  contract 
wordt  een  synchronisatie  uitgevoerd,  waarbij  de  gegevens  die  aan  het  contract 
voldoen  worden  uitgewisseld.  Na  afloop  bevat  de  database  de  correcte 
uitgangstoestand. 

Door  zoveel  mogelijk  statische  informatie  al  vooraf  in  de  databases  te  plaatsen  kan 
de  synchronisatie  kort  gehouden  worden  (dit  is  afhankelijk  van  de  omvang  van  de 
database,  maar  tijdens  oefeningen  was  de  tijdsduur  bij  gebruik  van  ZODIAC 
ongeveer  4  minuten).  Bij  toepassing  van  ISIS  voor  TICCS  levert  dit  geen 
problemen  op  omdat  contracten  gedurende  langere  periode  geldig  zijn. 

8.4.3  Operationele  omstandigheden 

Als  aangenomen  wordt  dat  de  sessie  al  is  geopend  en  de  contracten  zijn  opgezet 
worden  alleen  de  gemuteerde  gegevens  die  in  het  contract  vallen  tussen  de 
knooppunten  uitgewisseld.  De  volgende  fasen  zijn  hierbij  te  onderscheiden: 
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Figuur  23:  Fasen  van  gegevensoverdracht  tijdens  operationele  omstandigheden. 


1.  Applicatie  plaatst  gegevens  in  de  applicatiedatabase.  Na  verwerking  van  de 
gegevens  in  de  database  zijn  deze  -  door  middel  van  notificatie  -  direct 
beschikbaar  voor  alle  andere  clients  binnen  hetzelfde  knooppunt. 

2.  De  gegevens  worden  vertaald  van  de  applicatiedatabase  naar  de 
uitwisselingsdatabase. 

3.  De  gegevens  worden  (asynchroon)  verplaatst  naar  de  uitwisselingsdatabase,  die 
fysiek  op  een  andere  machine  aanwezig  kan  zijn. 

4.  Het  replicatiemechanisme  gaat  na  of  de  gegevens  in  de  uitwisselingsdatabase 
voorkomen  in  de  afgesloten  contracten  met  andere  knooppunten.  Zo  nodig 
worden  extra  gegevens  verzameld  om  de  referentiele  integriteit  te  waarborgen. 

5.  De  gemuteerde  gegevens  worden  verzameld  en  -  met  behulp  van  de 
beschikbare  datacommunicatiemiddelen  -  verstuurd  naar  het  desbetreffende 
knooppunt.  De  periode  waarmee  dit  plaatsvindt  is  instelbaar  (ook  direct 
versturen  is  mogelijk).  Indien  (horizontale)  filtering  wordt  toegepast  dient  de 
periode  groter  gekozen  te  worden.  Indien  geen  (complexe)  filters  worden 
toegepast  kunnen  gegevens  direct  verstuurd  worden. 

6.  Het  replicatiemechanisme  op  het  ontvangende  knooppunt  voert  de 
binnenkomende  mutaties  uit  op  de  uitwisselingsdatabase. 

7.  De  gegevens  worden  vertaald  van  de  uitwisselingsdatabase  naar  de 
applicatiedatabase. 

8.  De  gegevens  worden  (asynchroon)  verplaatst  naar  de  applicatiedatabase;  ook 
deze  kan  fysiek  op  een  andere  machine  aanwezig  zijn. 

9.  Afhankelijk  van  de  instellingen  in  de  applicatie  wordt  de  applicatie 
genotificeerd  van  de  nieuwe  gegevens. 


Momenteel  duurt  het  uitwisselen  van  gegevens  tussen  twee  applicaties  op  twee 
verschillende  knooppunten  die  verbonden  zijn  door  een  ZODIAC  netwerk  onder 
normale  -  operationele  -  omstandigheden  gemiddeld  genomen  minder  dan  een 
minuut  (afhankelijk  van  de  omvang  van  de  transactie  en  de  belasting  van  het 
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netwerk).  Hierbij  dient  wel  opgemerkt  te  worden  dat  er  (nog)  geen  filtering  wordt 
toegepast.  Indien  wel  filtering  wordt  toegepast  wordt  emaar  gestreefd  de  gegevens 
binnen  10  minuten  bij  de  ontvanger  te  hebben. 

Het  replicatiemechanisme  kan  een  taak  tegelijkertijd  uitvoeren.  Indien  een 
transactie  wordt  uitgevoerd  net  nadat  het  knooppunt  bezig  is  met  het  verwerken  van 
een  bulk  is  het  gevolg  hiervan  dat  de  transactie  moet  wachten  totdat  de  bulk 
compleet  is  verwerkt.  Dit  is  een  van  de  redenen  waarom  contracten  in  principe  voor 
langere  tijd  aangegaan  moeten  worden. 

8.4.4  Knooppunt  is  tijdelijk  niet  bereikbaar 

Na  elke  gegevensuitwisseling  stuurt  de  ontvanger  -  automatisch  -  een 
ontvangstbevestiging  naar  de  zender.  Hierop  wordt  ten  hoogste  een  half  uur 
gewacht.  Indien  de  ontvangstbevestiging  binnen  die  tijd  niet  wordt  ontvangen 
wordt  het  bericht  nogmaals  verstuurd.  Deze  procedure  wordt  ten  hoogste  drie  maal 
herhaald.  Heeft  het  ontvangende  knooppunt  nog  steeds  niet  gereageerd  dan  wordt 
uiteindelijk  de  sessie  met  dat  knooppunt  verbroken  (de  genoemde  frequentie  en 
tijden  zijn  wijzigbaar). 

Indien  de  verbinding  op  tijd  is  hersteld  worden  de  tot  dan  toe  opgespaarde 
gegevens  uitgewisseld.  Hierbij  wordt  de  volgorde  van  de  mutaties  in  stand 
gehouden.  Als  de  achterstand  is  weggewerkt  worden  de  gegevens  op  de  normale 
manier  uitgewisseld. 

Indien  ISIS  wordt  toegepast  voor  de  C2-onderlaag  moet  er  rekening  mee  gehouden 
worden  dat  de  verbindingen  niet  altijd  optimaal  zijn  en  soms  weg  kunnen  vallen. 

De  protocollen  dienen  hierop  aangepast  te  worden. 

8.4.5  ISIS  en  HERDS 

Hoewel  de  HERDS  interface  momenteel  op  het  niveau  van  het  legerkorps  wordt 
gelegd  en  derhalve  buiten  de  scope  van  dit  onderzoek  valt,  wordt  toch  kort 
aangegeven  welke  fasen  te  onderscheiden  zijn  bij  het  converteren  van  HERDS 
berichten  naar  ISIS  en  viceversa. 

Als  voorbeeld  wordt  uitgegaan  van  een  bericht  dat  vanuit  ISIS  (via  TICCS)  naar 
HERDS  wordt  geconverteerd. 
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Figuur  24:  HEROS  gekoppeld  am  ISIS. 


1.  Het  bericht  (momenteel  own-  of  enemy  sitrep)  wordt  in  ISIS/TICCS  opgesteld. 
Hiervoor  zijn  twee  mogelijkheden  aanwezig: 

•  Het  bericht  wordt  als  tekstbericht  in  een  ISIS-template  ingevoerd. 

•  Er  wordt  een  oleaat  in  het  ISIS-GIS  aangemaakt  waarop  de  own-  of  enemy 
sitrep  grafisch  wordt  ontwikkeld.  Als  het  oleaat  compleet  is  wordt  hiervan 
-  automatisch  -  een  ADatP-3  bericht  gecreeerd.  In  enkele  gevallen  is 
handmatige  nabewerking  noodzakelijk. 

2.  Het  ADatP-3  bericht  wordt  via  Email  verstuurd  naar  AMOR  (Automated 
Messagehandling  Object  Oriented)  workstation.  Hiervoor  worden  beschikbare 
communicatiemiddelen  zoals  ZODIAC  gebruikt. 

3.  De  gebruiker  achter  het  AMOR-workstation  haalt  het  bericht  uit  de  mailbox  en 
verstuurt  het  naar  de  HEROS-cel. 

4.  Gelijktijdig  wordt  het  bericht  vertaald  (in  dit  geval  van  het  Engels  naar  het 
Duits)  en  in  de  HEROS  database  opgeslagen. 

Omdat  momenteel  alleen  own-  en  enemy  sitreps  worden  ondersteund  en  hierbij 
geen  rekening  wordt  gehouden  met  TICCS  specifieke  gegevens  zullen  niet  alle 
TICCS  gegevens  naar  ADatP-3  berichtenformaat  geconverteerd  kunnen  worden. 

Als  mogelijke  oplossing  dienen  meer  ADatP-3  berichten  ondersteund  te  worden  of 
dient  het  ADatP-3  berichtenformaat  uitgebreid  te  worden.  Omdat  dit  formaat  een 
NAVO-standaard  is  zal  uitbreiding  niet  zondermeer  mogelijk  zijn. 

De  tijdsduur  die  verstrijkt  na  het  vertalen  van  het  oleaat  en  het  beschikbaar  zijn  van 
de  gegevens  binnen  HEROS  bedraagt  (bij  een  goede  verbinding  en  een  alerte 
AMOR-operator)  ongeveer  5  minuten.  Berichten  die  vanuit  HEROS  afkomstig  zijn 
kunnen  in  het  algemeen  niet  extreem  tijdkritisch  genoemd  worden.  Er  wordt 
daarom  niet  verwacht  dat  de  hiervoor  benodigde  tijdsduur  problemen  zal  opleveren. 
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8.4.6  Het  stellen  van  prioriteiten 

Binnen  ISIS  worden  de  gegevens  in  volgorde  van  binnenkomst  verwerkt;  alle 
gegevens  hebben  in  principe  dezelfde  (verzend)prioriteit.  Op  divisie-  en 
brigadeniveau  is  er  ook  geen  directe  noodzaak  tot  het  stellen  van  verzend- 
prioriteiten;  de  stafprocessen  zijn  in  het  algemeen  niet  tijdkritisch  en  de 
bandbreedte  vormt  geen  beperking.  Gegevens  worden  vrijwel  direct  en  ongefilterd 
naar  de  belanghebbende  knooppunten  verstuurd. 

Indien  er  toch  een  noodzaak  blijkt  te  bestaan  tot  het  kunnen  stellen  van  prioriteiten 
voor  de  C2-bovenlaag  dan  kunnen  de  volgende  oplossingsrichtingen  ingeslagen 
worden: 


►  Conv«nBon.t»  (»pticab.w»g 


_ Ttjdkillsdie  w»g 


Figuur  25:  Scheiding  van  tijdkritische  herichten. 


•  Introduceer  een  speciaal  'tijdkritisch  kanaal'.  Berichten  met  een  hoge  prioriteit 
kunnen  via  dit  tijdkritische  kanaal  verzonden  worden.  Het 
replicatiemechanisme  zal  voor  deze  gegevens  geen  filtering  en  forwarding 
toepassen.  Voorwaarde  is  dat  de  gegevens  met  hoge  prioriteit  geen  (of 
beperkte)  afhankelijkheid  hebben  met  andere  gegevens  in  de  database.  De 
applicatie  zal  ervoor  zorg  moeten  dragen  dat  hieraan  voldaan  wordt. 

Voor  de  communicatie  van  tijdkritische  gegevens  is  het  daamaast  niet  gewenst 
dat  er  vooraf  sessies  geopend  worden  (in  ATCCIS  ook  wel  'one-shot- 
replication'  genoemd).  Ook  zal  de  protocoloverhead  geminimaliseerd  moeten 
worden  en  zal  bij  elke  'terugmelding'  nagegaan  moeten  worden  of  dit  echt 
noodzakelijk  is. 

•  Pas  het  replicatiemechanisme  zodanig  aan  dat  tijdkritische  gegevens  met 
voorrang  behandeld  worden  (het  versturen  gebeurt  dus  over  hetzelfde  kanaal 
als  de  niet  tijdkritische  gegevens).  Ook  hier  geldt  dat  er  geen  afhankelijkheden 
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mogen  zijn  met  andere  gegevens.  Bovendien  geldt  dat  het 
replicatiemechanisme  aangepast  moet  worden  om  gelijktijdig  meer  processen 
uit  te  voeren. 

•  Stel  een  separaat  datamodel  op  de  specifiek  toegesneden  op  de  gegevens  met 
hoge  prioriteit  en  waarin  zo  min  mogelijk  afhankelijkheden  met  andere 
gegevens  voorkomen.  Ook  hier  geldt  dat  een  kanaal  gereserveerd  moet  worden 
om  de  gegevens  te  alien  tijde  zo  snel  mogelijk  te  versturen  (analoog  aan  het 
voorgaande  altematief). 

Van  en  naar  lagere  niveaus,  maar  vooral  tussen  lagere  niveaus  is  het  kunnen  stellen 
van  prioriteiten  van  groot  belang.  De  nadruk  komt  hier  steeds  meer  te  liggen  op 
uitvoerende  processen  die  tijdkritisch  zijn.  Juist  op  lagere  niveaus  -  waar  geen 
ZODIAC  voorhanden  is  -  is  de  beschikbare  bandbreedte  beperkt. 

8.4.7  Het  afbeelden  van  doelinformatie  op  het  ISIS  GIS 
De  gegevens  die  afkomstig  zijn  van  de  TICCS  radar  dienen  zichtbaar  gemaakt  te 
worden  op  een  werkstation  op  de  batterij  en  ook  op  de  brigade  /  divisie.  In  het 
kader  van  de  integratie  met  ISIS  heeft  het  voordelen  als  dit  op  een  ISIS  station 
afgebeeld  kan  worden  (hardware  besparing  en  een  uniforme  interface).  Voor  de 
fiinctionele  aspecten  van  het  afbeelden  van  doelinformatie  wordt  verwezen  naar 
paragraaf  7.3. 

Er  zijn  daarom  korte  testen  uitgevoerd  om  na  te  gaan  of  dit  een  haalbaar  altematief 
is.  Met  andere  woorden  'is  het  mogelijk  om  30  bewegende  doelen  binnen  twee 
seconden  op  het  GIS  af  te  beelden?'.  Gebleken  is  dat  het  niet  noodzakelijk  is  de 
historic  van  de  doelen  in  de  eigen  database  vast  te  leggen.  Er  wordt  daarom  van 
uitgegaan  dat  de  gegevens  buiten  de  database  om  (afkomstig  van  de  FM9000  en 
dan  via  files  of  rechtstreeks  in  het  geheugen)  aangeleverd  zullen  worden. 

De  testen  zijn  uitgevoerd  op  een  Satellite  Pro  430  CDT  met  48  MB  intern 
geheugen  (een  'lichte'  configuratie).  De  resolutie  is  1024  x  768  (16  bits  kleuren). 
Het  gebruikte  GIS  heeft  versie  1.18.  Voor  de  achtergrond  is  een  kaart  van  20  MB 
genomen  (een  laag  detailniveau)  die  op  de  harddisk  aanwezig  was.  Op  de  kaart 
werden  steeds  30  doelen  op  willekeurige  posities  geplaatst. 
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De  volgende  prestaties  zijn  gemeten: 


label  4:  Meetresultalen  bij  het  presenteren  van  30  bewegende  doelen  in  het  GIS. 


Actie 

Tijd  (sec.) 

Omperking 

Aanmaken  nieuw  oleaat  en  het  voor  de 
eerste  keer  plaatsen  van  30  symbolen. 

9 

Deze  actie  kan  in  de 
toekomst  bij  het  opstarten 
van  het  GIS  automatisch 
eenmalig  uitgevoerd 
worden. 

Refreshen  kaart  zonder  symbolen 
(schaal  1:1.400.000) 

1.0^ 

Refreshen  kaart  met  30  symbolen 
(schaal  1:1.400.000) 

1.9^ 

Ten  gevolge  van  het 
inzoomen  zijn  niet  alle 
objecten  zichtbaar. 

Refreshen  kaart  met  30  symbolen 
(schaal  1:140.000) 

1.5^ 

Ten  gevolge  van  het 
inzoomen  zijn  niet  alle 
objecten  zichtbaar. 

In  samenwerking  met  ISIS-mederwerkers  is  nagegaan  op  welke  punten  de 
performance  verbeterd  kan  worden; 

•  invoeren  van  lokale  updates,  waardoor  alleen  dat  gedeelte  hertekend  hoeft  te 
worden  waar  de  verplaatsing  plaatsvindt; 

•  invoeren  van  dubbele  buffering  van  de  kaart,  waardoor  de  kaart  niet  meer  uit 
het  bronmateriaal  opgebouwd  hoeft  te  worden,  maar  direct  uit  het  geheugen 
gekopieerd  kan  worden; 

•  de  grafische  objecten  in  een  ander  formaat  dan  het  Windows  Meta  Files 
(WMF)  formaat  vast  te  leggen. 

De  complete  kaart  werd  opnieuw  getekend  door  deze  opnieuw  op  te  bouwen  uit  de 
bronbestanden.  Door  alleen  het  gedeelte  te  hertekenen  waar  de  verplaatsing  zich 
afspeelt  kan  in  sommige  gevallen  tijdwinst  geboekt  worden.  Ook  de  genoemde 
dubbele  buffering  kan  aanzienlijke  tijdwinst  opleveren.  Doordat  de  achtergrond 
veel  'statische'  gegevens  bevat  waarop  niet  continu  wordt  ingezoomd  en  welke  niet 
steeds  worden  verschoven,  kan  de  geografische  achtergrond  in  een  'achtergrond- 
scherm'  worden  getekend  (zogenoemde  dubbele  buffering).  Bij  verplaatsingen  van 
objecten  kan  dit  achtergrond-scherm  naar  het  zichtbare  scherm  gekopieerd  worden 


^  Kan  tot  vrijwel  nul  gereduceerd  worden  indien  gebniik  gemaakt  wordt  van 
dubbele  buffering  van  het  kaartmateriaal. 

^  Indien  van  dubbele  buffering  gebruik  gemaakt  wordt  kan  de  genoemde  tijd  met  1 
seconde  verminderd  worden. 

^  De  resultaten  zijn  gemeten  op  een  Tecra  500  CDT  met  64  MB  intern  geheugen. 
De  kaart  werd  full-screen  afgebeeld  op  een  resolutie  van  800  x  600  met  16  bits 
kleuren.  De  benodigde  tijd  voor  het  uitrekenen  van  de  nieuwe  posities  van  de 
doelen  kost  verhoudingsgewijs  de  meeste  tijd.  Het  tekenen  sec.  kost  per  d^l  iets 
meer  dan  1  ms.  De  vermelde  tijden  bevatten  zowel  de  reken-  als  de  tekentijden. 
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(een  operatie  die  vrijwel  geen  tijd  kost),  waama  de  objecten  hier  overheen 
getekend  worden.  De  kaart  hoeft  dus  niet  steeds  opnieuw  uit  het  bronmateriaal 
opgebouwd  te  worden;  alleen  als  de  kaart  verschoven  wordt  of  een  zoom-operatie 
plaatsvindt.  Dit  geeft  bovendien  een  rustiger  beeld  voor  de  gebruiker  (geen 
storende  witte  vlakken  bij  verplaatsingen).  Bijkomend  voordeel  is  dat  de  tijdsduur 
benodigd  voor  het  afbeelden  van  de  kaart  onafhankelijk  is  geworden  van  de 
omvang  en  complexiteit  van  de  kaart  en  de  toegang  tot  het  bronmateriaal 
(netwerkbelasting,  belasting  server  etc.).  Voor  het  inzoomen  of  verschuiven  van 
de  kaart  zal  -  eenmalig  -  meer  tijd  benodigd  zijn. 

De  uitkomsten  moeten  gezien  worden  als  een  eerste  indicatie.  Ze  wijzen  erop  dat 
het  afbeelden  van  30  bewegende  doelen  op  het  GIS  binnen  2  seconden  geen 
problemen  geeft.  Door  het  optimaliseren  van  grafische  onderdelen  kunnen  de 
genoemde  tijden  nog  verder  verkort.  Verder  behoort  de  gebruikte  apparatuur  niet 
tot  de  snelste  ISIS  machines.  Bij  de  tijden  is  nog  geen  rekening  gehouden  met  het 
ophalen  van  de  gegevens  afkomstig  van  de  FM9000.  Door  de  opeenstapeling  van 
tijden  (o.a.  het  verzenden  van  de  gegevens  via  de  FM9000)  zal  het  beeld  wel  met 
enige  vertraging  zichtbaar  zijn  (de  gebruiker  'ziet'  het  beeld  van  enkele  seconden 
geleden). 

Voor  het  afbeelden  van  doelinformatie  wordt  voorgesteld  wel  gebruik  te  maken 
van  het  ISIS-framework.  Er  dient  dan  in  de  huidige  GIS-applicatie  een  add-in 
’doelinformatie'  ontwikkeld  te  worden.  Het  toevoegen  van  de  add-in  heeft  tot 
gevolg  dat  er  -  bovenop  de  gebruikte  oleaten  -  een  extra  oleaat  'doelinformatie' 
getoond  wordt.  Op  dit  oleaat  kan  -  net  zoals  bij  alle  andere  oleaten  -  filtering  etc. 
worden  toegepast.  De  functionaliteit  kan  uitgebreid  worden  door  het  spoor  van  het 
luchtdoel  gedurende  de  laatste  x  seconden  te  vertonen.  Op  deze  manier  kan  -  op 
een  zwarte  (of  geografische)  achtergrond  waarop  de  van  kracht  zijnde  Airspace 
Control  Means  zichtbaar  zijn  -  het  luchtbeeld  worden  geprojecteerd. 

Door  ISIS  is  in  korte  tijd  een  prototype  ontwikkeld  om  na  te  gaan  in  hoeverre  de 
aangegeven  performanceverbeteringen  realistisch  zijn.  Het  prototype  biedt  de 
mogelijkheid  een  willekeurig  aantal  doelen  te  genereren  die  zich  vervolgens  ieder 
langs  een  eigen  weg  en  met  een  eigen  snelheid  zullen  verplaatsen.  Er  is  hierbij 
gebruik  gemaakt  van  dubbele  buffering.  De  resultaten  zijn  erg  hoopgevend. 
Gebleken  is  dat  het  afbeelden  van  30  doelen  gemiddeld  slechts  220  ms.  duurt^  In 
onderstaande  grafiek  zijn  de  resultaten  voor  andere  aantallen  vermeld. 


^  De  resultaten  zijn  gemeten  op  een  Tecra  500  CDT  met  64  MB  intern  geheugen. 
De  kaart  werd  full-screen  afgebeeld  op  een  resolutie  van  800  x  600  met  16  bits 
kleuren.  De  benodigde  tijd  voor  het  uitrekenen  van  de  nieuwe  posities  van  de 
doelen  kost  verhoudingsgewijs  de  meeste  tijd.  Het  tekenen  sec.  kost  per  doel  iets 
meer  dan  1  ms.  De  vermelde  tijden  bevatten  zowel  de  reken-  als  de  tekentijden. 
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Figuur  26:  Benodigde  tijd  voor  het  tekenen  van  het  opgegeven  aantal  doelen  op  een 
geografische  achtergrond^. 


In  de  genoemde  tijden  dient  met  het  volgende  rekening  te  worden  gehouden: 

•  Er  is  geen  rekening  gehouden  met  binnenkomende  notificaties  ten  gevolge  van 
wijzigingen  in  de  ISIS-database  (bijvoorbeeld  door  het  toevoegen  van  een  Safe 
Lane).  Een  notificatie  zal  er  eenmalig  toe  leiden  dat  er  extra  tijd  nodig  is  om 
het  ISIS/nCCS  achtergrond-beeld  te  verversen.  Daama  gelden  weer  de 
genoemde  tijden. 

•  Er  is  geen  rekening  gehouden  met  een  groot  aantal  overlays.  Elk  overlay  kan 
een  bepaalde  tijd  consumeren  om  het  beeld  te  verversen. 

•  Bij  de  metingen  is  ervan  uitgegaan  dat  alle  doelen  werden  afgebeeld  als  cirkels 
met  een  korte  identificatie.  Indien  een  complexer  pictogram  wordt  gebruikt  zal 
iets  meer  tijd  benodigd  zijn  per  doel. 

•  Er  is  bij  de  tijden  geen  rekening  mee  gehouden  dat  de  gebruiker  tijdens  het 
afbeelden  veel  muisacties  uitvoert  (klikken  op  doelen  etc.). 

•  De  add-in  is  ontwikkeld  als  in-proces  DLL.  Dit  houdt  in  dat  het  proces  niet  als 
aparte  taak  wordt  behandeld  en  zijn  tijd  meet  delen  met  die  van  het  GIS. 

Gezien  de  uiteenlopende  gewenste  functionaliteiten  die  gelijktijdig  moeten  worden 
aangeboden  wordt  aanbevolen  hiervoor  een  speciaal  beeldscherm  te  reserveren.  Er 
dient  nog  te  worden  nagegaan  of  het  haalbaar  is  om  twee  beeldschermen  aan  e^ n 
werkstation  te  koppelen. 


*  Zoals  uit  de  grafiek  blijkt  kost  het  updaten  van  de  geografische  achtergrond 
(compleet  met  alle  ISIS-symbolen,  Airspace  Control  Means  etc.)  slechts  60  ms. 
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Er  moet  rekening  mee  gehouden  worden  dat  ook  niet  iua-onderdelen  (VUIST, 
S2/G2, ..)  in  de  toekomst  belangstelling  hebben  voor  de  doelgegevens.  Deze 
uitbreiding  valt  niet  onder  de  verantwoordelijkheid  van  het  TICCS,  maar  dient  wel 
mogelijk  te  zijn.  Indien  de  doelgegevens  via  de  FM9000  in  een  file  worden 
aangeleverd  kan  deze  distributie  binnen  een  knooppunt  met  behulp  \an  file¬ 
sharing  plaatsvinden  naar  andere  ISIS-stations  (zie  ook  figuur  17). 

8.4.8  Performanceverbeteringen 

Afgezien  van  het  efficignter  implementeren  van  algoritmen  en  het  aanschaffen  van 
snellere  hardware  is  op  een  aantal  fundamentele  punten  performancewinst  te 
behalen. 

Vertaling  applicatiedatabase  -  uitwisselingsdatabase 

Voor  de  vertaling  tussen  de  applicatiedatabase  en  de  uitwisselingsdatabase  zijn 
veel  -  verhoudingsgewijs  dure  -  databaseoperaties  noodzakelijk.  Bovendien  moet 
de  vertaling  zowel  op  de  zendende  als  de  ontvangende  kant  worden  uitgevoerd. 
Door  beide  databases  gelijk  te  houden  kan  een  zogenoemde  ‘nul-vertaling’ 
plaatsvinden.  In  dit  geval  worden  de  gegevens  alleen  getransporteerd  van  de  ene 
database  naar  de  andere. 

Een  stap  verder  kunnen  beide  databases  fysiek  gelijk  gehouden  worden.  Er  is  dan 
sprake  van  een  uitwisselingsdatabase  die  ook  gebruikt  wordt  als 
applicatiedatabase.  Een  nadeel  hiervan  is  echter  dat  de  structuur  van  de  database 
minder  goed  aansluit  op  de  applicaties.  Een  complexere  fiinctielaag  (tussen  de 
applicaties  en  de  database)  of  het  gebruik  van  aggregatietabellen  (tabellen  waarin 
de  gegevens  van  applicatieobjecten  die  verspreid  zijn  over  een  aantal  tabellen  - 
zoals  alle  informatie  van  een  eenheid  -  zijn  samengevoegd)  kunnen  de  twee  weer 
dichter  bij  elkaar  brengen. 

Filtering 

Het  selecteren  van  records  uit  de  database  die  aan  een  bepaald  criterium  voldoen 
(bijvoorbeeld  eenheden  die  binnen  een  bepaald  gebied  vallen)  kost 
verhoudingsgewijs  veel  tijd.  Door  het  achterwege  laten  van  deze  horizontale 
filtering  kan  veel  tijd  bespaard  worden.  Bovendien  wordt  het  dan  rendabeler  om  de 
gegevens  met  een  kleinere  periode  (of  eventueel  direct)  te  repliceren.  Met  name  in 
een  omgeving  waar  beperkte  bandbreedte  beschikbaar  is  wordt  op  deze  manier 
efficient  van  de  beschikbare  bandbreedte  gebruik  gemaakt.  Omdat  bij  het  niet 
toepassen  van  filters  alle  gegevens  gerepliceerd  worden  zal  een  afweging  gemaakt 
moeten  worden  tussen  het  repliceren  van  alle  gegevens  of  het  toepassen  van  filters. 

Efficientere  replicatieprotocollen 

Zowel  bij  het  opzetten  van  een  contract  als  tijdens  een  contract  worden  veel 
protocolgegevens  uitgewisseld.  Door  het  beperken  hiervan  kan  -  met  name  in  een 
omgeving  van  beperkte  bandbreedte  -  efficientieverbetering  worden  bereikt. 
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Broadcasting  van  data 

Indien  (dezelfde)  gegevens  naar  verschillende  gebruikers  verstuurd  moet  worden 
die  gelijktijdig  bereikbaar  zijn  is  het  -  in  het  bijzonder  in  een  smalbandige 
omgeving  en  veel  contracten  -  efficienter  om  de  gegevens  slechts  eenmaal  te 
versturen.  Momenteel  worden  de  gegevens  voor  ieder  knooppunt  apart  verstuurd. 
Om  dit  mogelijk  te  maken  dienen  de  replicatieprotocollen  aangepast  te  worden. 

Omdat  de  FM9000  volgens  het  broadcast  principe  werkt  (als  een  station  zendt 
dienen  alle  andere  stations  op  die  band  te  luisteren)  kan  hier  veel  tijdwinst  worden 
behaald. 

Strippen  van  uitwisselmodel 

Niet  alle  entiteiten  en  attributen  zijn  altijd  van  belang.  Door  deze  gegevens  niet  op 
te  nemen  in  het  model  hoeven  minder  gegevens  uitgewisseld  te  worden. 

Exchange 

Momenteel  wordt  voor  de  gegevensuitwisseling  tussen  twee  knooppunten  gebruik 
gemaakt  van  Exchange.  Gebleken  is  dat  dit  enige  overhead  kost,  met  name  als 
gebruik  wordt  gemaakt  van  kleine  gegevenspakketjes.  Bij  beperkte  bandbreedte  is 
het  efficienter  als  gegevens  zo  snel  mogelijk  verstuurd  worden  (in  tegenstelling  tot 
het  opsparen  van  gegevens  en  vervolgens  de  band  gedurende  enige  tijd  compleet 
reserveren).  In  dergelijke  situaties  kan  overwogen  worden  een  ander 
berichtenuitwisselingssysteem  te  kiezen. 

Parallellisme  binnen  replicatiemechanisme 

Het  replicatiemechanisme  is  momenteel  zodanig  van  opzet  dat  slechts  een  taak 
gelijktijdig  uitgevoerd  kan  worden.  Het  gevolg  hiervan  is  bijvoorbeeld  dat  nieuwe 
gegevens  pas  na  enige  tijd  in  de  database  worden  doorgevoerd  indien  replicatie  net 
bezig  is  om  een  synchronisatie  met  een  ander  knooppunt  uit  te  voeren.  Indien  het 
replicatiemechanisme  meer  taken  gelijktijdig  kan  uitvoeren  kan  in  dergelijke 
gevallen  tijdwinst  geboekt  worden.  Wei  moet  zeker  gesteld  worden  dat  de 
consistentie  van  de  database  niet  in  het  geding  komt. 

Bij  het  invoeren  van  parallellisme  kan  wellicht  rekening  gehouden  worden  met  het 
in  voeren  van  prioriteiten. 


8.5  Samenvatting 

Flexibiliteit  en  interoperabiliteit 

De  doelstelling  van  ISIS  is  om  de  kern  van  de  C2-activiteiten  op  brigade-  en 
divisieniveau  af  te  dekken.  ISIS  vormt  hiermee  een  basis  voor  specifieke 
functionele  deelgebieden  zoals  vuursteun  en  logistiek.  Naarmate  het  aantal 
functionele  deelgebieden  toeneemt,  neemt  ook  de  behoefte  filtering  toe,  niet 
elk  functioneel  deelgebied  is  immers  geinteresseerd  in  alle  gegevens  van  andere 
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functionele  deelgebieden.  Dit  gaat  met  name  een  rol  spelen  als  de  beschikbare 
bandbreedte  beperkt  is.  Momenteel  worden  binnen  ISIS  alle  gegevens  van  een 
specifieke  eigenaar  ongefilterd  doorgegeven. 

Voor  interoperabiliteit  met  buitenlandse  legeronderdelen  is  binnen  ISIS  de 
HEROS-gateway  ontwikkeld.  Gegevens  die  hiervan  afkomstig  zijn  kunnen  in  de 
toekomst  ook  door  de  lua  gebruikt  worden.  Momenteel  zijn  er  nog  geen 
operationele  ATCCIS-systemen  waarmee  gegevens  uitgewisseld  worden;  wel 
wordt  binnen  ATCCIS  gewerkt  aan  operationalisering  van  bet  concept. 

Communicatie  brigade  -  batterij 

De  batterijcommandant  is  wisselend  aanwezig  op  de  batterij  en  brigade.  Op  zowel 
de  brigade  als  de  batterij  dient  een  werkstation  beschikbaar  te  zijn.  Probleem 
hierbij  is  dat  de  batterij  alleen  over  een  FM9000  verbinding  met  de  brigade 
beschikt.  Om  ook  hier  de  gewenste  ondersteuning  te  bieden  wordt  voorgesteld  een 
ISIS-station  te  gebruiken  dat  op  zowel  de  brigade  als  de  batterij  ingezet  kan 
worden.  Daamaast  dient  aansluiting  gezocht  te  worden  met  de  ontwikkelingen  die 
plants  vinden  op  bet  gebied  van  commandovoeringssystemen  op  de  lagere  tactiscbe 
niveaus  (BMS  /  ISIS-ligbt).  Dergelijke  systemen  dienen  uit  te  gaan  van  beperkte 
communicatiefaciliteiten  en  'naadloos'  aan  te  sluiten  op  ISIS. 

Robuustheid  en  betrouwbaarheid 

De  lua  moet  te  alien  tijde  baar  taak  kunnen  uitvoeren;  ook  als  bet  systeem  of 
gedeelten  ervan  niet  meer  operationeel  zijn.  Bij  uitval  van  ISIS-apparatuur  kunnen 
voorzieningen  getroffen  om  snel  weer  inzetbaar  te  zijn  (specifieke  hardware  en 
noodprocedures).  Bij  uitval  van  de  communicatiemiddelen  wordt  voorgesteld  de 
gegevensuitwisseling  op  de  conventionele  wijze  te  ondersteunen.  Het  moet  dan 
mogelijk  zijn  om  vanuit  een  oleaat  de  tekstuele  ACO's,  ACM’s  en  overige 
bericbten  te  kunnen  genereren  en  deze  in  te  lezen.  Ook  eventuele 
‘eigenaarsproblemen’  dienen  biervoor  opgelost  te  worden. 

Performance  en  prioriteiten 

Het  opbouwen  van  bet  lucbtbeeld  kan  met  kleine  aanpassingen  gerealiseerd 
worden;  30  doelen  kunnen  dan  binnen  2  seconden  op  bet  ISIS-GIS  worden 
afgebeeld.  Hierbij  is  de  tijdsduur  van  de  dataoverdracbt  van  de  TICCS-sensor  naar 
bet  presentatie-systeem  niet  meegenomen. 

Voor  wat  betreft  performance  zijn  er  voor  de  reguliere  verspreiding  van  ACO’s, 
ACM’s,  rapportages  en  bevelen  geen  problemen  te  verwacbten. 

Bij  minute-to-minute-control  ligt  dit  anders.  Deze  gegevens  bebben  een  bogere 
prioriteit  dan  de  overige  gegevens.  Gesteld  is  dat  de  gegevens  binnen  een  minuut 
tot  op  bet  laagste  niveau  bekend  moeten  zijn.  Gegevensuitwisseling  tussen  twee 
knooppunten  van  de  C2-bovenlaag  zal  met  bebulp  van  ISIS  onder  normale 
omstandigbeden  binnen  een  minuut  plaatsvinden  (ongefilterd),  waarbij  nog  geen 
rekening  is  gebouden  met  de  distributie  binnen  de  C2-onderlaag.  Indien  dit  wel 
wordt  meegenomen  blijkt  bet  noodzakelijk  belangrijke  bericbten  met  een  boge 
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prioriteit  te  kunnen  verzenden.  Om  dit  mogelijk  te  maken  is  aantal  fundamentele 
aanpassingen  in  ISIS  noodzakelijk.  Deze  hebben  vooral  betrekking  op  de 
combinatie: 

•  communicatiemiddelen; 

•  replicatiemechanisme; 

•  datamodel. 


9. 


Conclusies,  risico's  en  aanbevelingen 


9.1  Conclusies 

r/CCS-  versus  ISIS-gegevens 

Het  ISIS-uitwisselmodel  (bedoeld  voor  de  uitwisseling  van  gegevens  met  andere 
knooppunten)  dekt  een  groot  gedeelte  van  de  TICCS-gegevensbehoefte  af;  met 
name  de  ‘Actie*  gerelateerde  entiteiten  bieden  mogelijkheden  om  het  gevecht,  de 
benodigde  middelen  en  de  bereikte  resultaten  vast  te  leggen,  Deze  entiteiten  zijn 
(nog)  niet  beschikbaar  in  het  ISIS-applicatiemodel  (dit  model  wordt  rechtstreeks 
gebmikt  door  de  applicaties).  Bij  Airspace  Control  is  een  aantal  attributen  van 
belling  die  gerelateerd  zijn  aan  de  Airspace  Control  Mean  (bijv.  Safe  Lane  en 
Weapon  Free  Zone).  In  het  ISIS-uitwisselmodel  dienen  extra  gegevens  toegevoegd 
te  worden  om  dit  mogelijk  te  maken.  Daamaast  zal  het  ISIS-uitwisselmodel  op  een 
aantal  -  minder  complexe  -  punten  uitgebreid  moeten  worden.  Het  betreft  hier 
vooral  het  gebruik  van  referentiepunten,  default-waarden  afkomstig  uit  de 
Standing  Operating  Procedures,  kennisgeving  van  ontvangst  en  relaties  tussen 
verschillende  entiteiten. 

Er  zijn  beperkte  aanpassingen  aan  het  ISIS-uitwisselmodel  nodig  om  de  complete 
TICCS-gegevensbehoefte  afte  kunnen  dekken.  Het  ISIS-applicatiemodel  zal  wel 
uitgebreid  dienen  te  worden  om  de  gegevens  van  het  ISIS-uitwisselmodel  aan  de 
applicaties  beschikbaar  te  stellen. 

Communicatie-aspecten 

De  ISIS  communicatie-infrastructuur  voor  Command  &  Control  bestaat  op  divisie- 
en  brigadeniveau  voomamelijk  uit  ZODIAC.  Dit  communicatiemedium  wordt  - 
behalve  voor  algemene  Command  &  Control  gegevens  -  ook  (in  de  toekomst) 
gebruikt  door  specifieke  functionele  deelgebieden  zoals  logistiek  en  vuursteun. 
Naarmate  er  meer  functionele  deelgebieden  gebruik  maken  van  de  C2- 
infrastructuur  ontstaat  er  ook  meer  behoefte  om  gebruik  te  kunnen  maken  van 
filters,  zodat  een  eenheid  niet  alle  gegevens  van  een  gespecificeerde  gebruiker 
aangeleverd  krijgt.  Binnen  ISIS  wordt  hiervan  nog  geen  gebruik  gemaakt.  Dit 
hangt  vooral  samen  met  het  feit  dat  er  momenteel  nog  geen  behoefte  aan  bestaat  en 
er  voldoende  bandbreedte  beschikbaar  is. 

Momenteel  worden  de  communicatiemiddelen  niet  alleen  voor  datacommunicatie 
gebruikt,  maar  ook  voor  voice-communicatie.  Het  is  daarom  ’gevaarlijk*  om  in  dit 
stadium  uitspraken  te  doen  over  de  toereikendheid  van  de  beschikbare 
bandbreedte.  Metingen  tijdens  oefeningen  hebben  tot  nu  toe  geen  aanleiding 
gegeven  om  te  veronderstellen  dat  de  bandbreedte  tekort  schiet.  Ook  zijn  de 
processen  op  brigade-  en  divisieniveau  in  het  algemeen  niet  extreem  tijdkritisch; 
geruime  tijd  van  tevoren  is  bekend  welke  gegevens  waar  aanwezig  dienen  te  zijn; 
de  tijdsduur  van  de  dataoverdracht  is  hierbij  dus  minder  relevant. 
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Een  uitzondering  hierop  vormt  de  'minute-to-minute-controV.  Incidenteel  dienen 
gegevens  met  de  hoogste  prioriteit  tot  op  het  laagste  niveau  te  worden 
doorgegeven,  bijvoorbeeld  voor  het  creeren  van  een  'safe  lane'  om  helikopters 
veilig  door  de  eigen  linies  te  loodsen.  Voor  TICCS  is  gesteld  dat  het  versturen  van 
deze  gegevens  tot  op  het  laagste  niveau  maximaal  een  minuut  mag  duren.  Ook 
andere  systemen  stellen  dergelijke  eisen.  Binnen  de  C2-bovenlaag  wordt 
gedeeltelijk  aan  deze  eis  voldaan:  onder  normale  omstandigheden  (werkende 
communicatiemiddelen  etc.)  zijn  de  gegevens  binnen  een  minuut  op  een  ander 
knooppunt  {in  de  C2-bovenlaag)  aanwezig,  hiervoor  kan  echter  geen  harde 
garantie  gegeven  worden.  Om  meer  zekerheid  te  hebben  dat  gegevens  binnen  de 
gestelde  tijd  aankomen  moet  het  mogelijk  zijn  prioriteiten  te  kunnen  stellen,  zodat 
de  gegevens  via  een  andere  weg  of  met  voorrang  behandeld  kunnen  worden.  In  dat 
geval  zijn  extra  aanpassingen  aan  ISIS  noodzakelijk  (zie  hiervoor  Architectuur). 

Een  belangrijk  aandachtspunt  vormt  de  verbinding  met  het  batterijniveau.  Voor 
communicatie  met  de  brigade  heeft  men  hier  alleen  de  beschikking  over  de 
FM9000,  die  in  tegenstelling  tot  ZODIAC  werkt  volgens  het  broadcast-principe; 

'als  een  station  zendt,  dienen  alle  andere  stations  op  die  band  te  luisteren'.  Het  ligt 
voor  de  hand  om  de  C2-infrastructuur  voor  de  lagere  tactische  niveaus  hierop 
zoveel  mogelijk  te  laten  aansluiten.  Als  de  ontwikkelingen  voor  BMS  of  een  ander 
C2-systeem  voor  de  lagere  tactische  niveaus  in  een  verder  gevorderd  stadium  zijn 
kan  meer  duidelijkheid  gegeven  worden  over  de  performance  van  de 
communicatiemiddelen  als  geheel  (C2-onder-  en  C2-bovenlaag). 

Binnen  de  C2-bovenlaag  wordt  -  onder  normale  omstandigheden  -  voldaan  aan  de 
gestelde  eisen.  Hiervoor  kan  echter  geen  garantie  gegeven  worden.  Indien  dit  wel 
noodzakelijk  is  zullen  architecturele  voorzieningen  getrqffen  moeten  worden  (zie 
ook  'Architectuur').  Op  het  gebied  van  communicatie  kan  de  C2-onderlaag  niet  los 
gezien  worden  van  de  C2-bovenlaag. 

Functionaliteit 

Veel  van  de  gewenste  Airspace  Control  functionaliteit  bestaat  uit  (geo)grafische 
manipulaties  op  een  stafkaart.  Een  voorbeeld  hiervan  is  het  samenstellen  van  een 
Airspace  Control  Order.  Voorgesteld  wordt  speciale  'Current-ACO'-  en  'Next- 
ACO'-oleaten  te  ontwikkelen  die  de  gegevens  vanuit  verschillende  bronnen 
(legerkorps,  divisie  en  brigade)  inzichtelijk  maken  en  actueel  houden.  Voor  ACM- 
requests  kan  een  identieke  werkwijze  gehanteerd  worden.  Hierbij  zal  het  gebruik 
van  het  ISIS-framework  zeer  veel  ontwikkelwerk  besparen.  Dit  geldt  ook  voor  het 
ondersteunen  van  de  conventionele  ACO's,  wat  grote  overeenkomsten  vertoont  met 
het  converteren  van  HEROS  berichten  naar  een  oleaat  in  het  ISIS-GIS  en 
viceversa. 

Voor  minute-to-minute-control  zal  de  user-interface  op  een  aantal  punten 
aangepast  moeten  worden  zodat  de  gebruiker  snel  en  eenvoudig  Airspace  Control 
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Means  kan  vastleggen.  Indien  het  stellen  van  prioriteiten  noodzakelijk  blijkt  zijn 
veranderingen  in  de  architectuur  noodzakelijk  (zie  Architectuur). 

Het  omgaan  met  bevelen  en  orders  is  grotendeels  al  aanwezig  in  ISIS.  Voor  de 
distributie  wordt  gebruik  gemaakt  van  het  Tactical  Message  System,  waarbij  de 
Subject  Indicator  Codes  (SICs)  de  distributie  binnen  een  eenheid  bepaalt.  Hiervoor 
zal  een  aantal  aanvullende  templates  ontwikkeld  dienen  te  worden. 

Het  presenteren  van  luchtdoelinformatie  wordt  momenteel  niet  ondersteund  in 
ISIS.  Testen  hebben  uitgewezen  dat  met  relatief  weinig  inspanning  ook  deze 
functionaliteit  ontwikkeld  kan  worden. 

Om  het  verloop  van  het  gevecht  vast  te  leggen  (wie  heeft  met  welke  middelen 
welke  actie  uitgevoerd  en  met  welk  (eind)resultaat)  wordt  voorgesteld  gebruik  te 
maken  van  de  'Actie'  structuur  zoals  die  in  het  ISIS-datamodel  is  vastgelegd.  Voor 
de  manipulatie  van  de  bijbehorende  gegevens  zal  nieuwe  functionaliteit 
ontwikkeld  moeten  worden. 

Door  gebruik  te  maken  van  het  ISIS-framework  kan  zeer  veel  ontwikkelwerk 
bespaard  worden  bij  de  ontwikkeling  van  TICCS-functionaliteit  voorde  C2- 
bovenlaag.  Op  een  beperkt  aantal  punten  zal  het  bestaande  ISIS-GIS  aangepast 
moeten  worden  om  aan  de  gestelde  eisen  te  kunnen  voldoen.  Ook  het  afbeelden 
van  luchtdoelinformatie  is  met  behulp  van  het  framework  -  met  relatief  weinig 
inspanning  -  mogelijk. 

Architectuur 

Naarmate  er  meer  functionele  deelgebieden  aansluiten  op  ISIS  neemt  de  behoefte 
aan  filtering  toe.  Deze  functionaliteit  is  weliswaar  aanwezig  is  ISIS,  maar  nog  niet 
gebruikt.  Dit  hangt  direct  samen  met  feit  dat  binnen  ISIS  momenteel  alle  gegevens 
direct  -  en  ongefilterd  -  gerepliceerd  worden  naar  andere  knooppunten.  Indien 
filtering  toegepast  zou  worden  kost  dit  enige  tijd  (bij  gebruik  van  complexe  filters 
wordt  emaar  gestreefd  de  gegevens  binnen  10  minuten  op  de  knooppunten 
aanwezig  te  laten  zijn). 

Binnen  TICCS  zijn  filters  nodig,  maar  is  het  tegelijkertijd  nodig  dat  de  gegevens 
direct  verstuurd  worden  (bij  minute-to-minute-control).  Er  dient  een  aantal 
performance-verbeterende  factoren  (en  eventueel  wijzigingen  in  de  architectuur) 
uitgevoerd  te  worden  om  dit  mogelijk  te  maken. 

De  communicatie  met  de  batterij  verloopt  -  zoals  het  zich  nu  laat  aanzien  -  via  een 
FM9000  verbinding.  De  batterijcommandant,  die  zich  afwisselend  op  de  brigade- 
en  batterij-commandopost  begeeft,  dient  op  beide  posten  dezelfde  functionaliteit 
tot  zijn  beschikking  te  hebben.  Indien  gekozen  wordt  voor  ISIS-functionaliteit  op 
de  brigade  dient  de  buitenkant  van  het  C2-systeem  op  de  batterij  in  elk  geval  een 
ISIS-look-and-feel  te  hebben.  Wordt  gekozen  voor  een  BMS-systeem  op 
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batterijniveau,  dan  dient  hetzelfde  systeem  ook  op  de  brigade  beschikbaar  te  zijn. 
Onduidelijk  is  momenteel  nog  hoe  de  C2-informatievoorziening  binnen  de  C2- 
onderlaag  zal  worden  gerealiseerd.  Duidelijk  is  wel  dat  er  een  'vertaling'  zal 
moeten  plaatsvinden  om  de  C2-functionaliteit  van  de  C2-onderlaag  naadloos  te 
laten  aansluiten  op  die  van  de  C2-bovenlaag.  Pas  als  deze  functionaliteit 
gerealiseerd  is  zijn  uitspraken  te  doen  over  de  performance  van  het  totale  C2- 
communicatie  gedeelte  van  TICCS. 

Robuustheid  en  betrouwbaarheid  zijn  belangrijke  eisen  die  aan  TICCS  gesteld 
worden;  de  lua  meet  immers  onder  alle  omstandigheden  haar  taken  kunnen 
uitvoeren,  ook  als  gedeelten  van  het  systeem  zijn  uitgevallen.  ISIS  zal  daarom 
verder  'gestabiliseerd'  moeten  worden  om  aan  deze  eis  tegemoet  te  komen.  Indien 
het  systeem  desondanks  niet  beschikbaar  is  wordt  voorgesteld  functionaliteit  in  te 
bouwen  die  aansluiting  geven  op  de  manier  waarop  momenteel  gewerkt  wordt  (o.a. 
ACO's  in  tekstueel  formaat  kunnen  genereren  en  inlezen). 

Over  de  te  verwachten  performance  kunnen  de  volgende  uitspraken  gedaan 
worden: 

•  Het  is  mogelijk  om  -  gebruik  makende  van  het  ISIS-framework  -  30  doelen 
binnen  2  seconden  af  te  beelden  op  het  ISIS-GIS.  Voorwaarde  is  wel  dat  de 
gegevens  via  een  altematieve  manier  (niet  via  de  ISIS-infrastructuur,  maar 
rechtstreeks  afkomstig  uit  de  FM9000)  aangeleverd  worden  en  niet  worden 
vastgelegd  in  de  ISIS-database. 

•  Bij  minute-to-minute-control  is  -  voor  divisie-  en  brigadeniveau  -  de  kans 
groot  dat  de  gegevens  binnen  de  gestelde  tijd  van  een  minuut  afgeleverd 
worden  (ongefdterd).  Hiervoor  is  echter  geen  garantie  te  geven.  Wordt  een 
dergelijke  garantie  wel  geeist,  dan  zullen  performance  verbeterende 
maatregelen  doorgevoerd  moeten  worden  en  zal  -  afhankelijk  van  het  resultaat 
hiervan  -  de  architectuur  op  een  aantal  punten  aangepast  moeten  worden.  Het 
gaat  hierbij  om  een  combinatie  van  de  onderdelen  replicatiemechanisme, 
database  en  communicatiemiddelen.  Een  van  de  gevolgen  hiervan  is  dat  het 
mogelijk  moet  zijn  om  (verzend)prioriteiten  te  kunnen  stellen,  hetgeen  bij  het 
huidige  ISIS-systeem  niet  mogelijk  is. 

•  Voor  reguliere  -  periodieke  -  gegevensoverdracht  (ACO  s,  ACM-reejuests  etc.) 
voldoet  het  ISIS-systeem  -  mits  voldoende  stabiel  -  aan  de  gestelde 
performance-eisen. 

•  Er  dient  een  afweging  gemaakt  te  worden  tussen  de  noodzaak  van  filtering  en 
het  direct  kunnen  versturen  van  gewijzigde  gegevens.  Binnen  ISIS  is  er 
momenteel  voor  gekozen  geen  filtering  toe  te  passen,  waardoor  gegevens 
direct  doorgestuurd  kunnen  worden  en  er  aan  de  performance-eisen  wordt 
voldaan.  Indien  wel  filtering  wordt  toegepast  is  de  kans  groot  dat  niet  aan  de 
gestelde  performance-eisen  wordt  voldaan.  Ook  in  dit  geval  zullen 
performance-verbeterende  maatregelen  doorgevoerd  moeten  worden  en  zal  - 
afhankelijk  van  het  resultaat  hiervan  -  de  architectuur  op  een  aantal  punten 
aangepast  moeten  worden.  Bij  toepassing  van  ISIS  voor  de  C2-onderlaag  is  het 


-  gezien  de  selectieve  informatiebehoefte  en  de  beperkte  bandbreedte  - 
noodzakelijk  dat  filtering  wordt  toegepast. 

•  Indien  meer  duidelijkheid  is  over  de  invulling  van  de  C2-functionaliteit  op  de 
lagere  tactische  niveaus  kunnen  uitspraken  worden  gedaan  over  de  totale 
performance  van  het  C2-gedeelte  van  TICCS  (zowel  C2-onder-  als  C2- 
bovenlaag). 

Indien  minute-to-minute-control  buiten  beschouwing  wordt  gelaten  voldoet  de 
huidige  ISIS-architectuur  -  mits  voldoende  stabiel  -  voor  de  TICCS  C2-bovenlaag. 
Zelfs  het  afbeelden  van  vijandelijke  luchtdoelinformatie  is  -  met  behulp  van  het 
ISIS-framework  -  relatief  eenvoudig  te  realiseren.  Wordt  minute-to-minute-control 
en  de  verbinding  met  de  C2-onderlaag  wel  meegenomen  dan  kunnen  geen 
garanties  gegeven  worden  dat  aan  de  performance-eisen  voldaan  wordt.  Er  zal 
een  aantal  performance  verbeterende  factoren  doorgevoerd  moeten  worden  en 
afhankelijk  van  het  resultant  hiervan  zal  de  architectuur  op  een  aantal  punten 
aangepast  moeten  worden  om  aan  de  gestelde  eisen  te  voldoen.  Het  is  hierbij 
nodig  dat  ook  van  filtering  gebruik  kan  worden  gemaakt  en  dat  prioriteiten  kunnen 
worden  gesteld.  Afhankelijk  van  de  invulling  van  de  C2-onderlaag  moet  bezien 
worden  tot  hoever  de  performance  van  de  C2-bovenlaag  verhoogd  moet  worden. 
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9.2  Risico’s 

De  mogelijke  risico’s  die  verbonden  zijn  aan  het  realiseren  van  TICCS  op  ISIS  zijn 
onderverdeeld  in: 

•  Organisatorische  risico's. 

•  Technische  risico’s. 

•  Overige  risico’s. 

Organisatorische  risico*s 

•  Organisatieveranderingen. 

Er  is  bij  dit  onderzoek  uitgegaan  van  de  huidige  lua-organisatiestructuur.  Het 
is  zo  goed  als  zeker  dat  deze  de  komende  jaren  zal  veranderen.  Dit  kan 
gevolgen  hebben  voor  de  te  bieden  functionaliteit  en  de  plaats  waar  deze 
functionaliteit  wordt  ondergebracht. 

•  Aansluiting  andere  functioned  deelgebieden. 

In  de  toekomst  zullen  ook  andere  ’functioned  deelgebieden’  aansluiting  zoeken 
op  ISIS.  Hierbij  is  de  kans  groot  dat  van  dezelfde  communicatiemiddedn, 
databases  etc.  gebruik  zal  worden  gemaakt.  Dit  kan  op  de  lange  duur  gevolgen 
hebben  voor  de  performance  van  het  systeem  als  geheel. 

•  Veranderende  gebruikersinzichten. 

De  functioned  specificaties  van  TICCS  zijn  in  dit  stadium  nog  niet  tot  in 
detail  geformuderd.  Het  gevolg  kan  zijn  dat  de  inzichten  van  de  gebruiker 
veranderen  hetgeen  zijn  weerslag  vindt  in  nieuwe  functioned  specificaties. 

•  Beschikbaarheid  van  gegevens. 

Van  een  aantal  gegevens  (zoals  vijand-informatie  en  informatie  betreffende  de 
derde  dimensie)  is  ervan  uitgegaan  dat  ze  in  TICCS  beschikbaar  zijn.  Door  wie 
deze  gegevens  ingevoerd  en  onderhouden  zullen  worden  is  nog  niet  bekend. 

•  Beschikbaarheid  ISIS-medewerkers. 

Door  het  ISIS-projectteam  is  inmiddels  erg  veel  ervaring  opgedaan  in  de 
ontwikkeling  van  GIS-functionaliteit.  Nog  niet  aid  resultaten  hiervan  zijn 
gedocumenteerd.  Hierdoor  zullen  ISIS-medewerkers  in  staat  zijn  snel 
produkten  te  ontwikkedn,  terwijl  dit  voor  ‘buitenstaanders’  relatief  meer  tijd 
kost.  Dit  geldt  in  het  bijzonder  als  ISIS  al  gerealiseerd  is  terwijl  met  de 
realisatie  van  TICCS  nog  moet  worden  begonnen. 

Technische  risico's 

•  De  performance  bij  minute-to-minute-control. 

Er  kan  geen  garantie  gegeven  worden  dat  aan  de  perfoimance-eisen  bij  minute- 
to-minute-control  voldaan  wordt.  Dit  hangt  direct  samen  met  het  feit  dat  het 
niet  mogelijk  is  om  prioriteiten  te  steldn.  Aanbevodn  wordt  om  dit  risico  te 
minimaliseren  door  in  een  vroeg  stadium  een  beperkt  prototype  te 
ontwikkedn. 

•  Gefilterde  gegevens  direct  versturen. 

De  combinatie  van  filtering  en  het  zo  snel  mogelijk  doorsturen  van  gemuteerde 
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gegevens  is  nog  niet  gebruikt.  De  vraag  is  of  bij  het  toepassen  van  deze 
combinatie  aan  de  performance-eisen  wordt  voldaan, 

•  Koppeling  C2-bovenlaag  met  C2-onderIaag. 

Bij  het  gebruik  van  ISIS  voor  de  C2-onderlaag  (ISIS-Iight)  moet  bijzondere 
aandacht  worden  geschonken  aan  de  communicatie  tussen  de  C2-onder-  en 
-bovenlaag.  Het  zal  hierbij  noodzakelijk  zijn  dat  er  een  snelle  vertaling 
plaatsvindt. 

•  Server-to-server  communicatie  over  FM9000. 

Er  is  nog  weinig  bekend  over  het  gedrag  van  het  systeem  als  de  replicatie  van 
gegevens  over  de  FM9000  zal  plaatsvinden.  Wellicht  kunnen  andere  software- 
produkten  of  protocollen  uitkomst  bieden. 

•  Gecombineerd  spraak  /  data  over  de  FM9000. 

Indien  voor  gegevensoverdracht  gebruik  wordt  gemaakt  van  de  FM90CK)  en 
ook  spraak  over  hetzelfde  kanaal  mogelijk  dient  te  zijn,  is  het  de  vraag  of  aan 
de  performance-eisen  wordt  voldaan. 

Overige  risico's 

•  Documentatie  ISIS-produkten. 

Nog  niet  alle  gerealiseerde  produkten  zijn  volledig  gedocumenteerd. 
Bovendien  neemt  het  aantal  mensen  bij  ISIS  dat  vanaf  het  begin  bij  de 
realisatie  betrokken  is  geweest  -  en  alle  ins  en  outs  van  het  systeem  kennen  - 
af.  Het  gevolg  hiervan  kan  zijn  dat  het  aanpassen  van  bestaande  functionaliteit 
en  het  realiseren  van  nieuwe  functionaliteit  extra  tijd  kost  en  er  onvoldoende 
beschikbare  realisatiecapaciteit  is. 
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9.3  Aanbevelingen 

Aanbevolen  wordt  in  eerste  instantie  de  voorheen  genoemde  risico’s  te 
minimaliseren.  In  eerste  instantie  zijn  dan  vooral  de  technische  risico’s  van  belang. 
Indien  nodig  kunnen  kleine  prototypen  /  demonstrators  worden  ontwikkeld  die 
uitsluitsel  geven  over  de  te  nemen  risico’s.  De  gewenste  TlCCS-functionaliteit  kan 
-  door  gebruik  te  maken  van  het  ISIS-framework  -  zonder  noemenswaardige 
risico’s  gerealiseerd  worden. 

Concreet  worden  naar  aanleiding  van  het  onderzoek  de  volgende  aanbevelingen 
gedaan: 

1.  Ga  na  welke  soorten  van  filtering  gewenst  zijn  en  implementeer  het  meest 
complexe  filter.  Ga  na  wat  hiervan  de  performance  is  in  combinatie  met  het 
replicatiemechanisme.  Voer  zo  nodig  een  aantal  van  de  in  hoofdstuk  8 
genoemde  performance  verhogende  veranderingen  door.  Indien  de  gewenste 
performance  nog  niet  wordt  gehaald  volg  dan  aanbeveling  2.  Wordt  de  vereiste 
performance  wel  gehaald  dan  hoeft  aanbeveling  2  niet  opgevolgd  te  worden. 

2.  Pas  de  architectuur  aan  totdat  wel  aan  de  vereiste  performance  wordt  voldaan 
(zie  hoofdstuk  8).  Het  wordt  hierbij  ten  sterkste  aanbevolen  om  het 
replicatiemechanisme  zodanig  aan  te  passen  dat  het  een  aantal  taken  parallel 
kan  uitvoeren  (en  zodoende  wellicht  ook  prioriteiten  kan  stellen  in  het 
verwerken  van  gegevens;  bijvoorbeeld;  het  verwerken  van  bulks  heeft  een 
extreem  lage  prioriteit  in  vergelijking  tot  het  verwerken  van  mutaties  in  de 
database). 

3.  Pas  het  ISIS-uitwisselmodel  en  het  ISIS-applicatiemodel  aan  op  de  in 
hoofdstuk  5  genoemde  punten  (toevoegen  entiteiten,  attributen  en  domeinen). 

4.  Ontwikkel  de  doelinformatie-component.  Deze  component  is  met  relatief 
weinig  inspanning  te  verwezenlijken.  Het  is  hiervoor  nodig  dat  de 
doelgegevens  via  een  FM9000  verbinding  vanuit  de  TICCS-radar  worden 
verstuurd  naar  een  ISIS-station. 

5.  Pas  de  functionaliteit  van  het  ISIS-GIS  aan  door  toevoegen  van  het  'Current 
ACO'-  en  'Next  ACO'-oleaat.  Dit  geldt  ook  voor  ACM-requests. 

6.  Voeg  functionaliteit  aan  het  ISIS-GIS  toe  om  ’acties’  te  kunnen  ondersteunen 
(zie  hoofdstuk  7).  Vanwege  het  generieke  karakter  hiervan  dient  deze 
functionaliteit  in  overleg  met  andere  legeronderdelen  ontwikkeld  te  worden. 

7.  Hoewel  dit  eigenlijk  buiten  de  context  van  dit  onderzoek  valt:  Ontwikkel  een 
systeem  dat  de  C2-functionaliteit  op  de  lagere  tactische  niveaus  ondersteunt 
(inclusief  de  interface  met  de  C2-bovenlaag)  en  ga  na  in  hoeverre  het  complete 
C2-gedeelte  aan  de  gestelde  eisen  voldoet.  Voer  indien  nodig  extra 
wijzigingen  door  die  genoemd  zijn  in  punt  1  en  2. 

8.  Bij  de  ontwikkelingen  van  de  C2-onderlaag  dient  de  koppeling  met  de  C2- 
bovenlaag  in  een  zo  vroeg  mogelijk  stadium  meegenomen  te  worden. 
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10.  Afkortingen 

ABDIS 

Automatisch  Berichtendistributiesysteem 

ACM 

Airspace  Control  Mean 

ACO 

Airspace  Control  Orders 

ACP 

Actieve  Commando  Post 

ADatP-3 

Allied  Data  Publication  Number  3 

ADCIS 

Air  Defence  Command  and  Information  System  (UK) 

ADSIA 

Allied  Data  Systems  Interoperability  Agency 

AG 

Applicatiegroep 

AMOR 

Automated  Messagehandling  Object  Oriented 

ARM 

ATCCIS  Replicatie  Mechanisme 

ASC 

Airspace  Control 

ASM 

Airspace  Management 

ATCCIS 

Army  Tactical  Command  and  Control  Information 
System 

AWACS 

Airborne  Warning  and  Control  System 

BAME 

Brigade  Airspace  Management  Element 

BKA 

Bedrijfs  Kantoor  Applicaties 

BMS 

Battlefield  Management  System 

BO 

Beslissingsondersteunend  Oleaat 

bps 

Bits  per  seconde 

C2 

Command  and  Control 

CNR 

Combat  Net  Radio 

COA 

Commandant  Achtergebied 

COTS 

Commercial  of  the  Shelf 

CP 

Commando  Post 

DAME 

Divisie  Airspace  Management  Element 

DBT 

Digitaal  Beveiligd  Telefoontoestel 

DCC 

Datacommunication  Card 

EMn 

Eigen  Mogelijkheden 

FAAD/C3 

Forward  Area  Air  Defence  C3  System 

EEC 

Forward  Error  Correction 

PEL 

Fysisch  en  Electronisch  Laboratorium 

GIS 

Geografisch  Informatie  Systeem 

HEROS 

Heeres-  Fiihrungsinformationssystem  fiir 
Operationsfuhrung  in  Staben 

HFlaAFuSys 

Heeres  Flugabwehr  Aufkl^ngs-  und  FiihrungsSystem 
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ISCU 

Information  System  Connection  Unit 

ISDN 

Integrated  Services  Digital  Network 

ISIS 

Geintegreerd  Staf  Informatie  Systeem 

KL 

Koninklijke  Landmacht 

KLIM 

KL  Implementatie  Middenlaag 

kvo 

kennisgeving  van  ontvangst 

LLAPI 

Low  Level  Air  Picture  Interface 

LOS 

Line  of  Sight 

lua 

luchtdoelartillerie 

MAP 

Multiplexer  Access  Point 

MAPI 

Mail  Application  Programming  Interface 

MDTN 

Militair  Dienst  Telefoon  Netwerk 

MLUZ 

Mid  Life  Update  ZODIAC 

NAVO 

Noord  Atlantische  VerdragsOrganizatie 

NIPD 

NATO  Interoperability  Planning  Document  (ADSIA) 

OA 

Operatic  Analyse 

OBP 

Operationeel  Besluitvormings  Proces 

OLVD 

Objectgebonden  Luchtverdediging 

ORBAT 

Order  of  Battle  (Gevechtsorganisatie) 

palua 

pantser  luchtdoelartillerie 

PC 

Personal  Computer 

PRTL 

Pantser  Rups  Tegen  Luchtdoelen 

PTT 

Post  Telefoon  Telegraaf 

RCP 

Reserve  Commando  Post 

RVC 

Rayon  Verbindingscentra 

SA 

Schakelautomaat 

SATCOM 

Satelliet  Communicatie 

SHAPE 

Supreme  Headquarters  Allied  Powers  Europe 

SIC 

Subject  Identifier  Code 

SM 

Synchronisatiematrix 

SOP 

Standing  Operating  Procedures 

STANAG 

Standard  NATO  Agreement 

SVC 

Staf  Verbindingscentra 

THG 

Tactische  Helikopter  Groep 

TI 

Target  Information 

TICCS 

Target  Information  Command  and  Control  System 

TMS 

Tactical  Message  System 

TNO 

Organisatie  voor  Toegepast  Natuurwetenschappelijk 
Onderzoek 

TRIAD 

Tripple  Air  Defence 
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UTP 

Unshielded  Twisted  Pair 

VMn 

Vijandelijke  Mogelijkheden 

vtg 

Voertuig 

VUIST 

Vuursteun  Informatie  Systeem 

WAN 

Wide  Area  Network 

WBU 

Wapen-  en  Commandosystemen  Bedrijfs  Unit 

WMF 

Windows  Meta  File 

ZODIAC 

Zone  Digitaal  Automatisch  Cryptografisch  beveiligd 
netwerk 
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A.1 


Bijiage  A  Lua-specijReke  berichtenstromen 


Overzicht  van  de  lua-specifieke  berichten  die  tussen  legerkorps,  divisie  en  brigade 
worden  uitgewisseld. 


ACO 

Zender  ->  Ontvanger: 

Legerkorps  ->  Legerkorps 

Legerkorps  ->  Divisie 

Divisie  ->  Divisie 

Divisie  ->  Brigade 

Verwachte  verzendfrequentie: 

1  maal  per  12  uur. 

Omvang: 

2-3  A4. 

Verzendprioriteit: 

Hoog. 

Voor  een  vooraf  vastgestelde  tijd  dient  het  bericht  bij  de 
divisie  ontvangen  te  zijn.  Deze  deadline  is  hard. 

In  de  oude  situatie  dienden  er  nog  veel  handmatige 
bewerkingen  plaats  te  vinden  die  straks  geautomatiseerd 
zullen  worden. 

Kvo: 

Vereist. 
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A.2 


ACM  Request 

Tender  ->  Ontvanger: 

Divisie  ->  Legerkorps 

Legerkorps  ->  Legerkorps  (afschrift) 

Legerkorps  ->  (Neven)divisies  (afschrift) 

Legerkorps  ->  COA  (afschrift) 

Legerkorps  ->  THG  (afschrift) 

Brigade  ->  Divisie 

Divisie  ->  Brigade  (afschrift) 

Divisie  ->  THG 

THG  ->  Divisie 

Verwachte  verzendfirequentie: 

1  maal  per  12  uur. 

Omvang: 

1-3  A4. 

Verzcndprioriteit: 

Normaal. 

Voor  een  vooraf  vastgestelde  tijd  dient  het  bericht  bij  het 
legerkorps  ontvangen  te  zijn.  Deze  deadline  is  hard. 

In  de  oude  situatie  dienden  er  nog  veel  handmatige 
bewerkingen  plaats  te  vinden  die  straks  geautomatiseerd 
zullen  worden. 

Kvo: 

In  de  huidige  situatie  wordt  een  ontvangstbewijs 
afgegeven  die  alleen  in  uitzonderingssituaties  als  bewijs 
wordt  gebruikt. 

ADINTSUM 

Tender  ->  Ontvanger: 

Legerkorps  ->  Divisie 

Divisie  ->  Legerkorps 

Divisie  ->  Brigade 

Brigade  *>  Divisie 

Verwachte  verzendfrequentie: 

1  maal  per  12  uur. 

Omvang: 

1-2  A4. 

Verzendprioriteit: 

Laag. 

Voor  een  vooraf  vastgestelde  tijd  dient  het  bericht  bij  de 
divisie  ontvangen  te  zijn.  Deze  deadline  is  hard;  hoe 
dichter  bij  de  deadline,  des  te  hoger  de  prioriteit. 

Kvo: 

In  de  huidige  situatie  wordt  een  ontvangstbewijs 
afgegeven  die  alleen  in  uitzonderingssituaties  als  bewijs 
wordt  gebruikt. 
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ADSITREP 

Zender  ->  Ontvanger: 

Legerkorps  ->  Divisie 

Divisie  ->  Legerkorps 

Divisie  ->  Brigade 

Brigade  ->  Divisie 

Verwachte  verzendfrequentie: 

1  maal  per  12  uur  of  vaker  indien  nodig 

Omvang: 

1-2  A4. 

Verzendprioriteit: 

Laag. _ 

Kvo: 

Geen. 

AIRINCIDENT 

Zender  ->  Ontvanger: 

Legerkorps  ->  Divisie 

Divisie  ->  Legerkorps 

Verwachte  verzendfrequentie: 

Bij  eerste  vijandcontact  en  na  incidenten;  Ad  hoc. 

Omvang: 

1-2  A4. 

Verzendprioriteit: 

Hoog,  moet  binnen  vastgestelde  tijd  worden  ontvangen. 

Kvo: 

Geen;  voorheen  impliciet  door  het  opzetten  van  de 
verbinding. 

Bevel 

Zender  ->  Ontvanger: 

Legerkorps  ->  Divisie 

Divisie  ->  Brigade 

Verwachte  verzendfrequentie: 

Indien  nodig  (gemiddeld  een  maal  per  dag). 

Omvang: 

Divisiebevel:  ±  30  A4  (inclusief  9  bijlagen). 

Brigadebevel:  20  -  30  A4  (inclusief  bijlagen). 

Verzendprioriteit: 

Nu  worden  de  bevelen  uitgedeeld  bij  de  bevelsuitgifte. 

Het  bevel  dient  ruim  voor  het  ingangstijdstip  ontvangen  te 
zijn. 

Kvo: 

Ja. 

HELIRAP 

Zender  ->  Ontvanger: 

Legerkorps  ->  Divisie 

Divisie  ->  Legerkorps 

Divisie  ->  Brigade 

Brigade  ->  Divisie 

Verwachte  verzendfrequentie: 

Bij  inzet  heli’s  (incidenteel). 

Omvang: 

1  *A4. 

Verzendprioriteit: 

Hoog. 

Kvo: 

Impliciet  door  het  opzetten  van  de  verbinding. 
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Minute-to-minute-control 

Zender  ->  Ontvanger: 

Legerkorps  ->  Divisie 

Divisie  ->  Brigade 

Verwachte  verzendfrequentie: 

Indian  op  korte  termijn  een  Mean  geactiveerd  moet 
worden;  Ad-hoc. 

Omvang: 

1  *  A4  (bijv.  voor  specificatie  van  een  Weapon  Free 

Zone). 

In  de  nieuwe  situatie  wil  men  alleen  die  eenheden 
restricties  opleggen  die  betrokken  zijn  bij  de 
gespecificeerde  Mean. 

In  de  oude  situatie  was  men  genoodzaakt  alle  eenheden 
die  restricties  op  te  leggen. 

Verzendprioriteit: 

Extreem  Hoog. 

Kvo: 

Vereist.  Niet  alleen  dat  de  boodschap  is  aangekomen, 
maar  ook  dat  deze  is  begrepen  tot  op  het  iaagste  niveau. 
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